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

[Martin Pitt]

Hello all,

Dan Nicholson [2010-01-04 16:06 -0800]:
> On Mon, Jan 4, 2010 at 3:05 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > ENV{ID_INPUT.tags}="DellInspiron BottomEdgeButtons"
> > EVN{ID_INPUT.synaptics_quirks}="JumpyCursorThreshold SlowMotion""

Right, that looks even better and avoids "xorg" specifics.

> >
> > Either way, by having the MatchTag option parse two string values the actual
> > tag naming is up to the distro and I guess after a bit of experimentation
> > we'll likely settle into something that should be shareable between the
> > distros.

We should not design it to be distro specific, since the quirks won't
be, but above system looks generic and flexible enough.

> I'm pretty indifferent on the best way for the backend to handle this.
> One thing I'd be worried about is making this tag system too
> udev-specific. Ideally, anything appear in InputClass could be
> provided by any config backend including hal and whatever Alan comes
> up with for Solaris.

As Peter says, it's not udev specific. The udev implementation of a

  MatchTag "synaptics_quirks"

would be to look for the INPUT_ID.synaptics_quirks property. In hal it
would look for an input.synaptics_quirks property. In a hypothetical
file-based configuration backend it could read the tags from
/etc/foobar/synaptics_quirks.

> I'm starting to come around to just adding a new match for DMI
> information. Surely this won't be the last time a product is quirky on
> hardware from one OEM or another. Adding a freeform, backend-dependent
> tagging system seems like it might be overkill.

DMI is good for OEMs because you can pinpoint hardware and avoid
regressions on any other, so having this possibility is very desirable. 

However, for rules shipped by upstream it's usually the least
desirable way, since you have to collect and maintain large lists of
vendor/models over time. 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.

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?

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/17c859cc/attachment.pgp