How to migrate the X server?

[Peter Hutterer]

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. 

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?

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.

Q2: How can we filter for event 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?
Q4: How can a user apply extra options to classes of devices?

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

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

Cheers,
  Peter