Hello Dan, Dan Nicholson [2010-01-05 6:19 -0800]: > On Mon, Jan 4, 2010 at 11:51 PM, Martin Pitt <[email protected]> wrote: > > In many cases it is hopefully possible to do > > more generic matching, combining properties and sysfs attributes of > > the affected device, other input devices, USB descriptors, etc. > > (Example: identifying touchpads, touchscreens, etc., as udev's > > input_id does.) If you want to replicate all of that in X.org, you are > > effectively reinventing udev rules or hal fdi files. > > Just because the property is exposed doesn't mean X.org needs to > maintain a pile of OEM workarounds.
Of course not, that's exactnly what I meant (we do not want to maintain large vendor/product lists upstream). > However, putting the trigger for the quirk in udev doesn't actually > change that decision either. Let's take the example of synaptics. > Wouldn't we end up maintaining this quirk in the xf86-input-synaptics > package? If it's generic enough and applies to all distros, we might? > If we did, would we really want to have one file per config backend > to describe that quirk? If we didn't want to maintain it, the quirk > tag name would still need to be coordinated between the synaptics > package and whoever is maintaining the udev rules file/hal > fdi/KitKit file/whatever. That's the obvious tradeoff, and also a reason why we shouldn't have too many of those backends. But coordination wise there isn't much of a problem; you certainly wouldn't put one half of a quirk upstream, but not the other half? On the other hand, if we are using udev on Linux and perhaps hal on Solaris, then the quirks will probably be pretty different anyway, due to the different kernels, input drivers, etc. > > If that's what it takes to make X.org platform independent, so be it. > > It just seems to be quite a lot of work to me? > > It would be more work to expose one string in our configuration than > to code from scratch a completely arbitrary tagging system with > multiple backends? Of course it would be simple to just expose DMI vendor/product for xorg.conf.d stanzas. My point is that this would then mean that we can _only_ use DMI vendor/product for the quirks, and not more generic information that we can get from other devices (with udev rules or hal fdis you can create matches on pretty much any device, DMI object, property, sysfs attribute, usb descriptor, and whatnot), but if possible at all we want way more generic matches than just particular computer models. So if you want the flexibility of matching that udev/hal give you, then reimplementing _that_ in X.org would be magnitudes more work than just reading a property from udev or hal (each of which is a three-liner). What if you want to key on a flag in the USB descriptor? Or a particular BTN_* or ABS_* input capability? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
