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

[Dan Nicholson]

On Mon, Jan 4, 2010 at 3:05 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Mon, Jan 04, 2010 at 10:27:51AM +0100, Martin Pitt wrote:
>> > yes, this was the idea, though we might need to think about namespacing the
>> > tags. some discussion with the udev guys would be beneficial here.
>>
>> Indeed, just using a "TAG" property is too generic. How about
>>
>>   ENV{ID_INPUT.xorg.InspironBottomEdge}="1"
>>   ENV{ID_INPUT.xorg.SlowMotion}="1"
>>
>>   MatchTag "InspironBottomEdge"
>>
>> This is assuming that you only want boolean matches and potentially
>> have more than one quirk. Then MatchTag "foo" would look for a set
>> ID_INPUT.xorg.foo property.
>>
>> If you want/can support string matches as well, this could look a tad
>> nicer:
>>
>>   ENV{ID_INPUT.quirks}="InspironBottomEdge SlowMotion"
>>
>>   MatchTag "quirks" "*InspironBottomEdge*"
>>
>> From an udev POV I'm not fussed about which to take. Here, udev just
>> provides a property database.
>
> I think strings give us better flexibility and better ability to group the
> tags. I'd like to see some tags to be more generic and less X.Org focused.
> For example, the Dell Inspiron bottom edge buttons aren't just a problem for
> the synaptics driver but would be for any software using the touchpad.
> Others may just be useful for X.Org, so having rules like the following may
> be useful for generic matching:
>
> ENV{ID_INPUT.tags}="DellInspiron BottomEdgeButtons"
> EVN{ID_INPUT.synaptics_quirks}="JumpyCursorThreshold SlowMotion""
>
> 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.
>
> Dan?

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. That would probably be secondary to actually
getting something working, though.

For the server, I think the ideal thing would be having the matches
single and boolean.

MatchTag "CrazyDevice" "yes"

where the tags are just an array of string/boolean structs. But it
would probably be easier to stuff all the tags into one string.

Thinking about this a bit more, though, I don't know if it's a great
improvement. You still have to provide the properties from the
backend, meaning you still have to create a backend-specific udev
rule/hal fdi/etc. That's in addition to the xorg.conf.d file to set
the Xorg-specific option. I don't know if that's a lot better than
just letting the backend specify options.

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.

--
Dan