How to migrate the X server?

[Kay Sievers]

On Thu, Jul 30, 2009 at 00:13, Peter Hutterer<peter.hutterer at who-t.net> wrote:
> I have poked at libudev a bit today in a weak effort to look what's required
> to switch the X server over. I'd be happy if someone else takes over at
> this, but right now I don't see this happening for 1.7 anyway. Especially
> since the udev code I just wrote required me to put a big "i know this API
> will change" define in.

That's gone since a while (also not in the udev version in rawhide).

> Anyway, a few questions came up and I'd appreciate a few pointers.
> Since I only just started this I have very limited knowledge of udev and
> it(')s magic. If the questions below can be answered with links to code
> samples or somesuch, that'd be good enough for me.
>
> Let me explain the current system based on HAL:
> The X server uses libhal to connect to HAL and asks it for the device list
> (libhal_find_device_by_capability(.. "input" ...)
> On top of that, it registers device_added and device_removed handlers.
>
> Once a device is added, the server extracts the following keys:
> - info.product, used as identifier for the device
> - input.device, the device node.
> - input.x11_driver, used as the driver to load up
> - input.xkb.{layout|model|variant|options} for
> - input.x11_options.XZY for all extra options
>
> The last three are user/distribution-configured. x11_driver is set by
> 10-x11-input.fdi shipped as part of HAL (in Fedora). The important thing is
> that the X server does not pick the driver, it doesn't set HAL keys, it
> doesn't do anything but listen to the things above.
>
> This configuration was also overwriting itself in parts. For example, a
> default match rule would assing the evdev driver for all devices and the
> wacom.fdi would then overwrite the one for wacom devices with
> input.x11_driver = 'wacom'. So if linuxwacom is installed you get wacom,
> otherwise evdev picks it up.
>
> I want to replicate this behaviour, the driver configuration should be
> external to the server and ideally chained so we cover most cases with the
> least amount of fuzz.
>
> Q1: How can this external driver configuration be achieved?

With udev rules, where later rules overwrite earlier ones.

The match/merge engine behind the HAL fdi files and the udev rules is
almost identical. Only the file format and the available strings to
match against differ.

> input.device always gives us a /dev/input/eventX file. mice are also added
> as /dev/input/mouseX but we don't see that and thus don't have to care.
> Looking at udevadm monitor and a simple test program, I don't see any
> differences between the messages for /dev/input/mouse and /dev/input/event
> other than the device path.

Yeah, they just share the same parent, which is the inputX device. The
mouseX and eventX are "interfaces" of the inputX device.

> Q2: How can we filter for event devices only?

The kernel socket filters support only matches by subsystem/devtype.
So all "input" class devices will arrive at the monitor socket, and
the not wanted ones can just be discarded when sysname != event*. We
can easily add a DEVTYPE to the kernel, which would allow the socket
filter to match on eventX devices only.

> For better or worse, a large number of users have their configurations in
> their fdi files. We need to provide some smooth transition from these
> configurations. The two types of configurations frequently seen are
> - device-specific configurations, matching on the product name, vendor, etc.
>  to apply certain settings to a single device.
> - type-specific configurations, matching on a class of devices
>  (input.touchpad) to apply settings to all devices within this class.
> A combination of both is not that uncommon either, and device specific
> configuration may also be used to blacklist certain devices.
>
> Q3: How can a user apply extra options to specific devices?

By providing custom udev rules with matches on specific devices.

> Q4: How can a user apply extra options to classes of devices?

Also with udev rules, with wider matches on a class of devices.

> Based on that, we might come up with some sort of transition plan or
> migration tool.

Yeah, Maybe Martin can take a look and suggest something, if we can
provide him with a few examples. He did most of the other fdi -> udev
conversion scripts.

> Those are the more high-level questions right now. Any hints are
> appreciated.

A trivial example for video devices is here:
  http://article.gmane.org/gmane.linux.hotplug.devel/13925

Thanks,
Kay