[PATCH 0/3] xfree86: Configure input devices by properties

[Dan Nicholson]

On Mon, Oct 5, 2009 at 2:57 AM, Michael Thayer <Michael.Thayer at sun.com> wrote:
> Dan Nicholson wrote:
>> These patches add support in xorg.conf to apply input configuration to a
>> class of devices by property. The idea is to offer similar property
>> matching capabilities to the hal fdi system. Moving the configuration
>> back into the ddx means that some day we can stop doing it from the
>> config backend and asking users to adjust to it.
> Sorry to be chipping in on this after you have written your patch, but
> I'm really wondering whether xorg.conf is the right place to put this
> sort of information.  It thought that the way things were currently
> moving was that xorg.conf was being deprecated as far as possible, and
> that nothing should go into xorg.conf which could reasonably be
> auto-detected.  Things like the the mapping between the evdev driver and
> /dev/input/event* (from the rule in your example) on Linux systems are
> well-known, and I would have thought hardly something that need to be
> specified in xorg.conf.

With the exception of the supplying the driver name, this is no
different than the current situation. If you supply no configuration,
you'll still get a device from hal and X will connect to it. This is
to address the times when you actually do need to change a driver
option and the defaults won't work for you. In that case, would you
rather explain to your users how to create a hal fdi file or a udev
rules file or trusty old xorg.conf, the Xorg configuration file?

The example I quoted was totally contrived and just meant to show the
possibilities. On linux, path based matching would be mostly
pointless.

> I should add that as someone who maintains a set of out-of-tree drivers
> complete with installation scripts (no, I'm not quite an impartial
> observer) I really like the fact that xorg.conf is being deprecated - to
> install on older versions of X.Org/XFree86, I have to hack xorg.conf
> using a script, which is not fun.  By way of comparison, hal can be
> configured by simply dropping a file into a directory.  I don't know how
> much out-of-tree drivers weigh in this though.

True. The single file xorg.conf is not a lot of fun. To that end, I'm
also working on a patch to make an xorg configuration directory.
Something like /etc/X11/xorg.conf.d/. The huge advantage of using
xorg.conf is that you and your users can be entirely ignorant of how
the event backend. Nobody enjoyed migrating their configurations to
hal (in fact many people are still fighting it), and hal is already
deprecated! At least on linux, the push is to get people off hal and
onto udev. Or maybe a new DeviceKit will show up. Or maybe on Solaris
they want to use a different mechanism. The point is that putting the
configuration in xorg.conf means these type of backend changes don't
have to have massive impacts on users.

> I'm afraid that I haven't yet thought this through enough to offer a
> well-thought-out alternative, as I didn't want to wait too long before
> starting a discussion.  I do have a couple of thoughts though - if
> device names are to be mapped to X.Org drivers directly, as in your
> example, then udev (or its equivalent, if any, on other systems) might
> not be such a bad place after all, as that is where device names are
> handled.  An alternative though, would be to hardcode the name(s) of the
> kernel driver(s) which correspond to the X.Org driver in the driver
> itself, and have the backend (udev or whatever) supply the kernel driver
> name along with the path to the device node.  I am assuming that the
> kernel driver names are relatively stable, and this seems to me like a
> reasonably platform-independent way of doing things.

Where the driver name comes from by default is the only tricky part
and it came up in the udev backend patch review.

http://lists.freedesktop.org/archives/xorg-devel/2009-October/002349.html

This patch doesn't preclude the driver name being supplied in the
configuration backend if that's easier. All my testing was on top of
my current hal configuration supplying it. Personally, I'd rather have
the driver name supplied in the X configuration. Another thought I had
is that maybe you get a builtin InputClass configuration that just
sets the default driver if you haven't supplied one.

> What other information is currently supplied via hal?  On my Ubuntu
> system, the only other information that I see is Debian-specific stuff
> relaying Debian keyboard configuration to X.Org.  Which really could be
> in udev, as the people writing it are probably reasonably familiar with
> it anyway.  I assume though, that there is other stuff which I'm not
> aware of, and which doesn't belong as well in udev/whatever.

Most importantly, the product name. That's usually how people narrow
down their hal fdi files to the device they want. Also, everything in
input.capabilities is pretty interesting.

Thanks for giving this some thought.

--
Dan