[PATCH] xserver: add udev/systemd multi-seat support

[Lennart Poettering]

On Wed, 20.07.11 06:08, Dan Nicholson (dbn.lists at gmail.com) wrote:

> > 3) We try to avoid setting pretty names in udev rules, since they might
> > need translations later on. Hence having a property like "NAME" here
> > isn't a good idea at all -- not even if you rename it.
> 
> This is already done in the kernel, so I don't see why we're doing
> anything wrong here.

Well, the current Wacom userspace rule adds in a pretty name in
userspace, which however is something we generally try to avoid, simply
because sooner or later people will ask that "Wacom Serial Tablet" shows
up as "Wacom Serielles Eingabetablett" on de_DE machines. Having pretty
names in such a low level database is problematic.

(Eventually we'll probably have some device databsae that will fix this
problem, but as long as that isn't around at least in udev upstream we
generally try to avoid attaching pretty names to devices within udev
rules, simply to keep this maintainable.)

> 
>     ATTRS{name}=="Silitek Standard USB Keyboard "

The kernel name is read directly from the USB descriptor, so is not our
own metadata but actually stored in an EEPROM on the USB device. So
using this information makes some sense.

> I'm pretty sure hal did the same thing, which is where I looked when I
> added that code. What I always thought would be much more appropriate
> is if one of the udev rules standardized this name under a
> ID_INPUT_NAME property or something like that. The other thing that
> always kind of bugged me here is that this is the name that's matched
> with MatchProduct and it's not really the product name, but that's
> another story.

Well, HAL is pretty good as an excercise how not do things ;-)

Most devices use ID_MODEL and ID_MODEL_FROM_DATABASE as generic model
description strings. The former is usually read from the device itself,
the latter comes from the lspci/lsusb database. In PulseAudio for
example we rely on these strings only. To make use of them you need to
hook the "pci-db" and "usb-id" helper tools.

If somebody wants to clean this up: Kay is happy to apply patches that
clean up the rules for the input deivces in udev upstream.

> > 6) Where a device shows up in the device tree is not considered ABI,
> > kernel devs are free and happy to add new layers to the tree where
> > necessary. That means in the X11 udev code you cannot use
> > udev_device_get_parent() to check the parent device of the wacom tablet,
> > assuming it was a pnp device. This is borked and will break at any
> > time. Use udev_device_get_parent_with_subsystem_devtype() instead, or
> > much better: assign the properties you are looking for to the serial
> > device itself, via the udev rule, by inheriting them as necessary.
> 
> This is something that affects the usb devices equally. We really need
> to get to the NAME and PRODUCT properties on the parent of the event
> node. Do you have a suggestion how that would be better solved in udev
> rules?

So, generally there are two approaches to this:

a) write your C code that it is able to go up the tree if it looks for a
certain property

or

b) write your udev rules so that it inherits properties down the tree.

I think b) is much smarter, and this is what most subsystems do. We do
that for sound cards (PulseAudio as a consumer) or block devices.

Now, as it turns out /lib/udev/rules.d/60-persistent-input.rules already
includes the right lines to inherit these properties down the tree, so
you can actually just use ID_MODEL_ID and ID_PRODUCT_ID on the device
itself and it will just work.

(Originally the udev driver in X11 appear to have done that. However, a
patch related to Bluetooth changed this. A patch that probably never
should have been merged in the first place. What it tried to fix is that
on bluetooth the ID_MODEL_ID/ID_PRODUCT_ID fields the USB dongle were
inherited by the bluetooth input device, which is something which
is a bad idea. Kay has now fixed the default udev rules not to inherit
USB metadata properties onto the devices connected to a bt dongle. This
should fix the issue and the X11 code should go back to using
ID_MODEL_ID/ID_PRODUCT_ID directly.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.