Monday, January 4, 2010

New configuration world order

In the last couple of weeks, Dan Nicholson and Julien Cristau have been working on revamping the X server configuration and hotplugging code, introducing a couple of new features. This work is now pulled into master and brings about a new way of configuring the X server.

The three new features are:

  • udev backend support

  • Support for an xorg.conf.d configuration directory

  • Support for matching rules in the xorg.conf

udev backend support

Back in 2006, support for hotplugged input devices was added and up to server 1.7, the incarnation worked with HAL as the provider of the input devices.
HAL is now deprecated and - at least under Linux - replaced with udev. Julien wrote a new backend that queries udev instead of HAL but otherwise follows the same principle:
Upon startup the X server queries the active backend for the list of input devices and initializes them accordingly. When a new device is added at runtime, the server is notified and adds it at runtime. HAL and udev are mutually exclusive, so enabling one disables the other. Currently, udev is disabled by default though I'd like to see it being default for 1.8.

On that note, users still confuse HAL and evdev though they have little to nothing to do with each other. The same is of course valid for the udev backend.

xorg.conf.d support

Over recent years, the xorg.conf support has moved towards two overlapping goals - support partial xorg.conf's with the server filling in the rest and removing the need for an xorg.conf entirely.
For most installations the server now has the right defaults and is usable without any configuration file. For the few cases where it is needed, a single section is often enough.

However, one remaining problem was that the xorg.conf is a single file and not easy to programmatically edit. Dan has now added support for a directory-based configuration. Again, the principle is simple: in addition to the xorg.conf file (if it exists), the /etc/xorg.conf.d/**.conf files are read and parsed as well. It performs like expected, with a section being added just as if it was present in the xorg.conf. Hence, a possible configuration may be:

:: whot@barra:~> ls -R /etc/xorg*

10-synaptics.conf 97-wacom.conf 99-evdev.conf

Note that the xorg.conf is parsed before the xorg.conf.d, hence it always has precedence. This allows for distributions to populate the xorg.conf.d directory with various quirks, yet still have user-specific configuration in the good old xorg.conf.

To better support snippet-based xorg.conf, a new tag has been introduced: AutoServerLayout. Traditionally, any input device needs to be referenced from the ServerLayout section to become active. With AutoServerLayout, an input device may be present in any layout. Hence, your input configuration may look something like this:

Section "InputDevice"
Identifier "touchpad"
Driver "synaptics"
Option "AutoServerLayout" "on"

Regardless of which layout is started, the touchpad will always be part of the input device list.

InputClass matching

With the hotplugging support, much of the configuration wandered into the HAL fdi files. This was never the best solution but at that time the only available one. With udev, the fdi files went away and instead of requiring users to port HAL-specific configuration to udev-specific configuration, Dan has stepped in and wrote a set of patches that allow similar functionality to the fdi configuration as part of the xorg.conf (or xorg.conf.d).

InputClasses are similar to InputDevices but can apply to multiple devices (and multiple classes may apply to one device). They work on match rules, with the following matches being available:

MatchProduct, MatchVendor, MatchDevicePath, MatchIsKeyboard, MatchIsPointer, MatchIsJoystick, MatchIsTablet, MatchIsTouchpad, MatchIsTouchscreen

Their meaning is what they describe, with the first three being substring matches, the others being binary matches. An input class is assigned to a device if all match rules apply. As an example, the following snippet would assign the synaptics driver to all touchpads:

Section "InputClass"
Identifier "synaptics-catchall"
Driver "synaptics"
MatchIsTouchpad "on"

Or, the catchall evdev rule that applies to every device.

Section "InputClass"
Identifier "evdev-catchall"
Driver "evdev"

Or, a more complicated example to set a specific option:

Section "InputClass"
Identifier "vendor-quirk"
MatchVendor "SomeVendor"
MatchDevicePath "/dev/magicdevice"
MatchIsTouchpad "on"
Option "Quirk" "on"

Input classes are cumulative and only apply if a given option hasn't been set yet. Hence, the first Driver match will apply and the evdev catchall needs to be the last file matched. This is a bit odd at first, but it again guarantees that the user-defined xorg.conf takes precedence.

We may see some more match conditions before 1.8 is released, but for now the ones above seem to suffice for the general cases.


slashdotaccount said...

Is anyone working on support for using fontconfig to configure the font setup?

Dan Nicholson said...

Thanks for writing that up. One very minor clarification: MatchDevicePath uses fnmatch(3) when available, so you can actually use a wildcard pattern.

MatchDevicePath /dev/input/event*

On Linux it's not terribly helpful since all the devices we care about have the same paths (except uinput), but maybe it'll come in more handy on another platform.

Alexander E. Patrakov said...

OK, how should I set the default keyboard layout and other Xkb options now?

Anonymous said...

@dan: you can add a udev rule to create some more symlinks:
IMPORT{program}="path_id %p"
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:3*", ENV{HUB}="left"
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:4*", ENV{HUB}="right

KERNEL=="event*", ENV{ID_BUS}=="?*", ENV{ID_CLASS}=="?*", SYMLINK+="input/by-hub/hub_$env{HUB}-event-$env{ID_CLASS}"
After that, you can use the path matches
Assumes to hubs connected to different usb ports

Alex Wauck said...

This sounds like the sort of thing that we should have had all along. I'm glad to see it becoming a reality at last.

arekm said...

How to configure keyboard stuff that previously lived in /etc/hal/fdi/policy/10-keymap.fdi (model, layout, variant, options etc) with udev backend?

Dan Nicholson said...

There are two ways to configure XKB settings. The purely InputClass way:

Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbLayout" "de"

The options can also be passed in through udev to system wide keyboard settings like /etc/sysconfig/keyboard:

ENV{ID_INPUT_KEYBOARD}=="?*", ENV{xkblayout}="de"

Coly Li said...

With the new features, is it possible to disable/enable an input device dynamically ? E.g disable/enable the touch pad/track point (as the device does not exist) whenever I want ?
If yes, it's really helpful for my laptop :-)

Unknown said...


are there any statements from distro maintainers regarding the integration of this release into a distro? Espacially Canonical?

Anonymous said...

My apologies, didn't realize I was commenting on a 2-year-old post. I was linked to it from

Is there any work on creating a property to set the button to use for pastebuffer access? For instance, so I could highlight and paste with button 6 instead of button 2?

Robert said...

Would this make it possible to configure multiple devices for an input, i.e. Wacom tablets stylus and eraser. These need to be configured as separate input devices even if they share the same device node.

As this is a TabletPC using old style xorg.conf is not possible due to the devices moving around after suspend.

Peter Hutterer said...

Fedora rawhide ships with all this since yesterday and it will be in Fedora 13.
Debian switched to udev a while ago and to the xorg.conf.d approach too but I don't know when exactly the second part happpend.

not related to this post, please raise this on the xorg mailing list so others can find the answers.

that's a specific feature of the wacom driver and the xf86-input-wacom driver already has this feature integrated (i.e. it hotplugs new devices from within the driver). this gets around this issue (in parts, anyway)

Isurinda Jayawardana said...

Dear Peter,
Where is your email address? couldn't find it. I have some questions regarding your multipoint x server like project.

Unknown said...

I'm exploring MPX on F12 (x server 1.7.5). Has anyone successfully compiled and run your XI2 sample application on F12?. As posted, it does not compile. Would it be possible to post an updated version on your blog, one that compiles and runs? Thanks

Peter Hutterer said...

@Miguel: I've removed part6.c (didn't compile due to a typo) because I don't really have a useful example program for the ClientPointer settings. the rest compiles fine on my F12 box.

Anonymous said...

can you please help me, I don't understand what I am doing wrong:

Anonymous said...

It's nice that you guys are supporting Linux more, but what about other operating systems that have had equivalent device filesystem support for much longer (FreeBSD, Mac OSX, NetBSD, OpenBSD, etc)? Is someone going to maintain a thin abstraction compatibility layer above the new code to ensure that Linux isn't the only supported platform?

Peter Hutterer said...

only the udev bit is Linux-specific. Platforms that don't have udev can continue to use HAL instead.