Hello all, Dan Nicholson [2010-01-04 16:06 -0800]: > On Mon, Jan 4, 2010 at 3:05 PM, Peter Hutterer <[email protected]> > 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)
signature.asc
Description: Digital signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
