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

[Peter Hutterer]

On Mon, Jan 04, 2010 at 04:06:16PM -0800, Dan Nicholson wrote:
> > 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.

the udev part is limited to a "this device needs a quirk" though. What that
quirk entails is dependend on the xorg configuration. it's not too unlikely
that the touchpads in the minis may be re-used in other devices. at which
point you need a new xorg.conf section _and_ a new udev rule for those.
having more generic tags allows you to label the device in udev only, the
xorg sections still apply.

same thing for configuration grouping. The InputClass sections dont do
nesting, so you'd end up replicating xorg.conf sections. For example, if you
have two devices that have a specific quirk each and a common quirk, you'd
be able to combine the common quirk into a single InputClass section based
on the tag.

also, with the DMI match you're still limited and there's likely a device in
the future that won't be handled with a DMI match because you need to check
the phase of the moon as well or something similar. So I figured we might as
well go for the full solution that doesn't require adding new matches in the
next server version.

Cheers,
  Peter