I've hesitated on replying to this email string for a while. With my limited view of X server (<a href="http://x.org">x.org</a> 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 :).<br>
<br>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 <a href="http://x.org">x.org</a>) 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 :).<br>
<br>So, I think the correct flow of this whole hotpluging/udev process would be:<br><br>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. <br>
<br>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. <br><br>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. <br>
<br>Let's take input devices, more specifically Wacom device since I know it, for example:<br><br>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. <br>
<br>I have one comment inline below.<br><br>Ping<br><br><div class="gmail_quote">On Mon, Dec 7, 2009 at 9:05 PM, Dan Nicholson <span dir="ltr"><<a href="mailto:dbn.lists@gmail.com" target="_blank">dbn.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Mon, Dec 7, 2009 at 6:47 PM, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>> wrote:<br>
> On Mon, Dec 07, 2009 at 06:33:41PM -0800, Alan Coopersmith wrote:<br>
>> Peter Hutterer wrote:<br>
>> > One more thing about this patchset. what's the behaviour if the server is<br>
>> > run with Xorg -config foobar.conf?<br>
>> ><br>
>> > Does it still scan xorg.conf.d? If so, we need an option to disable that so<br>
>> > one can force _only_ the use of a custom xorg.conf, without system<br>
>> > configurations interfering.<br></div></blockquote><div><br>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?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
>><br>
>> A command line option or a setting in the foobar.conf ?<br>
><br>
> I'd say a commandline option at least. I'm not sure how much use a .conf<br>
> option would be to disable scanning of the xorg.conf directory, it seems<br>
> execessive.<br></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
><br>
>> And while I'm here, while it's not a requirement for this patch set, should<br>
>> matching verbs be added for PCI ids -> video drivers as well, so that the<br>
>> nvidia package could install a conf.d file to map nvidia cards to it and<br>
>> the nouveau package could do the same to override the Xorg server builtin<br>
>> mapping? (Or radeon/radeonhd/fglrx.)<br>
><br>
> sounds good to me.<br>
<br>
</div>I thought about that a couple times, but I'm not exactly sure how it<br>
should work. "MatchPCI"? Wildcard patterns a la wordexp(3)?<br>
<br>
--<br>
<font color="#888888">Dan<br>
</font><div><div></div><div>_______________________________________________<br>
xorg-devel mailing list<br>
<a href="mailto:xorg-devel@lists.x.org" target="_blank">xorg-devel@lists.x.org</a><br>
<a href="http://lists.x.org/mailman/listinfo/xorg-devel" target="_blank">http://lists.x.org/mailman/listinfo/xorg-devel</a><br>
</div></div></blockquote></div><br>