Fwd: Re: xorg.conf.d - InputClass feature request

[Martin Pitt]

Hello Dan,

Dan Nicholson [2010-01-05  6:19 -0800]:
> On Mon, Jan 4, 2010 at 11:51 PM, Martin Pitt <martin.pitt at ubuntu.com> 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.x.org/archives/xorg-devel/attachments/20100105/eec5e6c6/attachment-0001.pgp