[PATCH] xfree86: Allow a config directory for multiple config files

[Ping]

I've hesitated on replying to this email string for a while.  With my
limited view of X server (x.org as well), I fear I am not seeing the whole
picture. However, for the sake of Wacom device driver, the worst response I
might get would be someone tells me that I don't know what I am talking
about.  If that happens, I still learn something. So, bear with me and let
the fool talk :).

I think the fundamental feature of a hotpluging enabled X server is it has a
default driver for each type, such as video, audio, input, etc, of the
supported devices.  You (I mean x.org) most probably have already had those
default drivers, I think.  But, a robustic X server should never let a
device driver crash  the server, which is not what I am seeing right now (I
can be wrong :).

So, I think the correct flow of this whole hotpluging/udev process would be:

For a specific device, the custom/user defined .conf get parsed first.  If
it passes, there is no need to process any global .conf for that device.

If it fails, parsing the vendor defined .conf under xorg.conf.d if there is
any.  If it passes, the device will be driven by these options.  If not, go
to globe xorg.conf if the device is defined there.

If it fails or is not defined in xorg.conf, the universal default options
for that device type kicks in to drive the device.  It would not support
most user specific options.  But it provides the very basic functionalities
of the same type of devices.

Let's take input devices, more specifically Wacom device since I know it,
for example:

If there is a ~/.xorg.conf defined with Wacom options, when the user logs
in, X server reads the options and let the device defined in ~/.xorg.conf
take control.  If it fails, xorg.conf.d/wacom.conf, which should be a global
.conf provided by xf86-wacom-input, kicks in.  If this one fails too or does
not exist, check xorg.conf.  If there is no Wacom sections defined there,
udev lets wacom_drv.so grab the device.  If this one fails (I truly hope it
won't :), X server lets evdev_drv.so grab the device and represent it as an
absolute input device by default. If we could allow the input device to tell
us it is a touchscreen device or not, that would great.

I have one comment inline below.

Ping

On Mon, Dec 7, 2009 at 9:05 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:

> On Mon, Dec 7, 2009 at 6:47 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> > On Mon, Dec 07, 2009 at 06:33:41PM -0800, Alan Coopersmith wrote:
> >> Peter Hutterer wrote:
> >> > One more thing about this patchset. what's the behaviour if the server
> is
> >> > run with Xorg -config foobar.conf?
> >> >
> >> > Does it still scan xorg.conf.d? If so, we need an option to disable
> that so
> >> > one can force _only_ the use of a custom xorg.conf, without system
> >> > configurations interfering.
>

As I mentioned above, I think once a  custom xorg.conf is detected for a
device, anything else (system wide xorg.conf or xorg.conf.d) will be
disabled by default for that device.  This is based on the assumption that
the user who has added the custom xorg.conf wants his options to be
processed.  If not, what the heck he is doing?

>>
> >> A command line option or a setting in the foobar.conf ?
> >
> > I'd say a commandline option at least. I'm not sure how much use a .conf
> > option would be to disable scanning of the xorg.conf directory, it seems
> > execessive.
>
 >
> >> And while I'm here, while it's not a requirement for this patch set,
> should
> >> matching verbs be added for PCI ids -> video drivers as well, so that
> the
> >> nvidia package could install a conf.d file to map nvidia cards to it and
> >> the nouveau package could do the same to override the Xorg server
> builtin
> >> mapping?   (Or radeon/radeonhd/fglrx.)
> >
> > sounds good to me.
>
> I thought about that a couple times, but I'm not exactly sure how it
> should work. "MatchPCI"? Wildcard patterns a la wordexp(3)?
>
> --
> Dan
> _______________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20091213/f6e39a3d/attachment.htm