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

[Dan Nicholson]

On Mon, Jan 4, 2010 at 11:51 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> 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.

Just because the property is exposed doesn't mean X.org needs to
maintain a pile of OEM workarounds.

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 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.

> 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?

--
Dan