xorg.conf.d - InputClass feature request

Dan Nicholson dbn.lists at gmail.com
Thu Jan 7 09:57:58 PST 2010

On Wed, Jan 6, 2010 at 8:32 AM, Alberto Milone
<alberto.milone at canonical.com> wrote:
> 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
>>  so.
>> Cheers,
>>   Peter
> 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
> suggested.
> In the case of udev, the udev rule will set the tags in the following way:
> ENV{ID_INPUT.tags}="DellInspiron BottomEdgeButtons"
> 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.

OK, I've come around to the idea of the tags system. If you want to
work on it, what you'll want to do is add a new tags member to
InputAttributes and populate it from the config/* backends. Then
you'll need to add a similar tags member to the InputClass struct in
hw/xfree86/parser/*. The matching is actually done in

One question: in the example above is the DellInspiron tag independent
of the BottomEdgeButtons tag? Is it just another tag, or is it trying
to imply something about the BottomEdgeButtons tag?


More information about the xorg-devel mailing list