xorg.conf.d - InputClass feature request
alberto.milone at canonical.com
Wed Jan 6 08:32:36 PST 2010
On Wednesday 06 Jan 2010 01:15:37 you wrote:
> The benefit of the tag system is that it's technically easy to implement
> and it gives us more flexibility than stricter matches like DMI. The rest
> is up to the usage of the tags and some may not be as pretty as others. As
> long as hardware vendors keep producing hardware, software vendors will
> need to keep producing hacks. But we might as well make it easier to do
Ok, I think we've gathered a few ideas now and we can start experimenting a
bit and see how it goes.
We can add the support for an additional string to the udev and hal backends
(which shouldn't be a lot of work) without caring why/how the tags end up in
this string. It can be because of DMI or anything else, as Martin and Peter
In the case of udev, the udev rule will set the tags in the following way:
In the case of hal:
<merge key="input.tags" type="string">"DellInspiron BottomEdgeButtons"</merge>
Then in X we use MatchTag "BottomEdgeButtons", etc. as discussed before.
I hope to be able to work on this soon so as to get some feedback.
In reply to Dan's concerns about quirks, I think we can safely leave their
integration, maintenance and use to OEMs and distributions in general and
limit ourselves to providing a generic system to enable the use of quirks,
without necessarily forcing their use.
Just to be clear, quirks will be applied if:
* distributions include configuration files in xorg.conf.d
* distributions include configuration files for the backend (e.g. udev rules,
hal fdi, etc.)
* X.Org supports the backend that the distribution uses (obviously)
If we decide to do so with quirks, it would still be useful to have a git
branch (separate from the driver) to collect these quirks so that it's easier
for distributions to see what is available and include what they prefer.
Just an idea.
What do you think?
Sustaining Engineer (system)
Canonical OEM Services
More information about the xorg-devel