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

[Dan Nicholson]

On Sun, Dec 13, 2009 at 12:05 PM, Ping <pinglinux at gmail.com> wrote:
> 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 think it will work the way you envision, but with the caveat that
there isn't any parsing of ~/.xorg.conf and never has been. After
that, it would work similarly to how you describe. xorg.conf is parsed
first and then the xorg.conf.d files are parsed afterwards, but their
contents are all mashed into one configuration structure. There is no
on-the-fly parsing of config files, but there doesn't need to be.
Earlier matches take precedence, so if the input device is fully
specified in xorg.conf, nothing happening in xorg.conf.d would have
any effect.

Speaking about the InputClass patches that would allow hal-style
attribute matching, this is how I would envision it working. If you
have the wacom driver installed, you'll also xorg.conf.d/50-wacom.conf
installed, which would set Driver for the devices it cared about. If
it wasn't installed, the device would get generic settings. Either
this would be built into the server, or there would be like a
xorg.conf.d/90-generic-input.conf that just matched all input devices
and set Driver to evdev (on Linux). As I mentioned above, any earlier
matches would override this.

> 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?

Yes, the patches generally work that way. Preference is given to the
earliest match, so nothing would happen in xorg.conf.d if the device
class was specified in xorg.conf.

I'll be reposting both sets of patches tonight.

--
Dan