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)
signature.asc
Description: Digital signature
_______________________________________________ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
