How to migrate the X server?

[Martin Pitt]

Hello Peter,

I'll try to fill in some places which Kay didn't answer yet.

Peter Hutterer [2009-07-30 14:13 +1000]:
> The X server uses libhal to connect to HAL and asks it for the device list
> (libhal_find_device_by_capability(.. "input" ...)

The libudev counterpart would be udev_enumerate_*() [1] with scanning for
the "input" subsystem, and then you could use
udev_device_get_devtype() to check for "event" (I didn't test this,
though).

[1] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-enumerate.html#udev-enumerate-scan-devices

> On top of that, it registers device_added and device_removed handlers.

The counterpart should be to register a monitor [2]
and poll() for events on udev_monitor_get_fd().
udev_monitor_receive_device() [3] will give you the udev_device struct to
check for udev properties and sysfs attributes [4].

The action ("added", "changed", "removed") can be retrieved from the
udev_device struct with udev_device_get_action() [5].

[2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html
[3] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html#udev-monitor-receive-device
[4] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-device.html
[5] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-device.html#udev-device-get-action

> Once a device is added, the server extracts the following keys:
> - info.product, used as identifier for the device

hal sets this from the "name" sysfs attribute for input devices.
Use udev_device_get_sysattr_value() [6]

[6] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-device.html#udev-device-get-sysattr-value

> - input.device, the device node.

udev_device_get_devpath()

> - 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

These were previously set by FDIs, and should be converted to udev
rules which attach properties (ENV{X11_XKB_LAYOUT}="de" etc.). I. e.
X.org should use udev-device-get-property-value() to get them.

[7] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-device.html#udev-device-get-property-value

> 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.

Right, same thing on Ubuntu and Debian. Our hal packages (including
Fedora) ship an addon which reads the system keyboard configuration
from /etc (it's /etc/default/console-setup for Ubuntu) and pokes it
into hal.

The equivalent udev counterpart would be a rule which attaches those
properties whenever an input device is added.

E. g. on Ubuntu:

$ grep ^XKB /etc/default/console-setup 
XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS="nodeadkeys"

Fedora uses a different file and perhaps a different format, but the
principle is the same. The distribution has to provide a
/lib/udev/getx11keymap callout which transforms those to something
like

$ /lib/udev/getx11keymap
X11_XKB_MODEL="pc105"
X11_XKB_LAYOUT="de"
X11_XKB_VARIANT=""
X11_XKB_OPTIONS="nodeadkeys"
X11_XKB_DRIVER="evdev"

Then an udev rule could look like

# 8042 internal keyboards
SUBSYSTEM=="input", ACTION=="add", ID_CLASS=="kbd", IMPORT{program}="getx11keymap"

> 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.

So the wacom driver should install udev rules which update
X11_XKB_DRIVER.

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

More custom udev rules.

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

That might be more tricky. We can write reasonable transition scripts
for known fdi files, such as in hal-info, but since hal fdis can
become arbitrarily complex (callouts, negations), and cannot always be
translated 1:1 to udev rules, a general automatic migration for user
supplied fdi files will not be reliable. Perhaps we should rather
document the properties that X.org understands, and some migration
guide for custom .fdi files.

Distro supplied fdi rules can be converted on the distro side, of
course.

HTH,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20090730/deca124d/attachment.pgp