On Fri, Jul 31, 2009 at 06:33:14AM -0700, Dan Nicholson wrote: > On Thu, Jul 30, 2009 at 6:49 PM, Peter Hutterer<[email protected]> > wrote: > > On Thu, Jul 30, 2009 at 08:21:52AM -0500, Dan Nicholson wrote: > >> On Wed, Jul 29, 2009 at 11:13 PM, Peter > >> Hutterer<[email protected]> wrote: > >> > I have poked at libudev a bit today in a weak effort to look what's > >> > required > >> > to switch the X server over. I'd be happy if someone else takes over at > >> > this, but right now I don't see this happening for 1.7 anyway. Especially > >> > since the udev code I just wrote required me to put a big "i know this > >> > API > >> > will change" define in. > >> > >> Peter, > >> > >> I've been working on some patches to add an InputClass configuration > >> in the anticipation that when udev hotplugging shows up to the server > >> so we don't have to attempt to migrate people to a udev configuration. > >> Would you consider having a look at the patches before we add yet > >> another input device configuration system? > > > > sure, just send them my way. Are we talking about similar patches you did > > ages ago to get xorg.conf and HAL together? > > Yes, but improved (IMO). I'm still not sure you'll like them, but this > adds an InputClass section where you can match on properties of the > device to apply settings. Basically, I think hal and udev should be > used for device notification and get out of the business of being our > configuration stores. > > Have a look at these two patches. There are some of improvements I > have in mind, but this is the gist of it. Also, I just rebased them to > master, so I'm not sure they even build. > > Let me know what you think.
First of all, a disclaimer: I haven't tested them and didn't look at the code, only the documentation. The basic approach is good, essentially duplicating the <match key contains> approach of fdis. The main issue I see is with the integration of distribution-shipped code and user-configured code. With the current system, we have /usr/share/hal/* for distro-code and /etc/hal/* for user-configured code. This is quite convenient as we can update device blacklists and other configurations while still maintaining user-specific configurations. Anything in the xorg.conf doesn't allow this, at least not easily. The other issue I can see with the this approach is the lack of information about the device that is outside of the scope of path and device names. For example, the input.touchpad capability was assigned based on what the device itself was able to do (BTN_TOUCH, amongst other things). This allowed for new devices to be supported automatically, without adding extra match rules. I don't see any way to do this in the InputClass approach, at least not without an external program or integrating these bits into the server itself. Personally I think this feature is even more important than the patch matching. Do you have any ideas on how to address these issues? > Basically, I think hal and udev should be used for device notification and > get out of the business of being our configuration stores. IMO there is nothing wrong with hal/udev being configuration _stores_. The bad thing is that they are also the configurators, i.e. that the configuration became part of HAL rather than the X package. However, right now I can only think of another process being the configuration store, adding the properties to udev for the server to pick it up (which, incidentally, would be quite similar to the original hotplug support (daniel's "respeclaration" tool)). my gut tells me that this isn't a good solution either though. Cheers, Peter _______________________________________________ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
