X input: devd, dbus, hald, evdev... ???

Jan Kokemüller jan.kokemueller at gmail.com
Sun Mar 5 18:06:35 UTC 2017

Hi Jon,

> I notice that the handbook
> (https://www.freebsd.org/doc/handbook/x-config.html) doesn't mention
> dbus or hald, so are they not needed any more? Is everything meant to be
> handled automatically through devd? Should I remove the hald_enable line
> from /etc/rc.conf? dbus_enable?

Yes, HAL has been deprecated by its upstream for quite some time now. 
Xorg on FreeBSD does not depend on HAL any more. On most Linux based 
systems HAL has been replaced by udev which is similar to devd on FreeBSD.

Xorg can do device detection statically (xorg.conf.d etc.), but the 
"modern" way is dynamically via libudev (on Linux) or a devd backend 
(default on FreeBSD):

> How does evdev/webcamd fit into the picture? I see that devd is starting
> an instances webcamd for my touchpad and touchscreen, but when I install
> xf86-input-evdev, it does funny things to my keyboard input.

evdev is Linux' input event interface. Every input device such as 
keyboards or mice have one or more nodes under /dev/input/. Its ioctl 
based API looks a bit funny 
(http://lxr.free-electrons.com/source/include/uapi/linux/input.h), but 
it's actually pretty flexible. It supports things as absolute touch 
coordinates, multiple finger tracking, horizontal scrolling and more 
(all those features are unsupported by the mouse(4)/sysmouse(4) protocol).

More recently, libinput has shown up. It is an input driver library that 
can be used stand alone, in Wayland or in Xorg via xf86-input-libinput. 
libinput does its own device detection with libudev and can attach to 
multiple evdev nodes at once. This is useful for features where you need 
input from multiple devices at the same time, for example palm detection 
(mouse+keyboard) or automatic disabling of the touchpad when the lid is 
closed. One instance of xf86-input-evdev can only attach to one 
/dev/input/event* device at a time I think. libinput also contains a 
touchpad driver that takes the raw multitouch events from evdev and 
transforms them into relative mouse movement. So xf86-input-libinput is 
also usable as a replacement for xf86-input-synaptics.

The specialized input device drivers such as xf86-input-mouse or 
xf86-input-keyboard are not really in use any more on systems that 
support evdev. xf86-input-evdev or xf86-input-libinput are used instead.

When using xf86-input-evdev/-libinput as the keyboard driver, the 
keycodes are slightly changed in comparison to the old 
xf86-input-keyboard driver. I'm not sure exactly why this is, but I need 
to configure my X keymap with the '-rules evdev' parameter like this 
(I'm using xf86-input-libinput for my keyboard, though):

     setxkbmap -rules evdev -layout us

Maybe X use evdev rules per default on your machine, but you actually 
need some other rules? Maybe playing around with some other rules in 
/usr/local/share/X11/xkb/rules helps?

> Should X be able to detect input devices under /dev/input automatically,
> or do I need to explicitly configure them? I think that I need an
> explicit driver config for my drm-next setup, so does that mean that I
> also need to create explicit ServerLayout, Screen, Keyboard, Mouse,
> etc., files in /usr/local/etc/X11/xorg.conf.d?

Xorg is supposed to automatically pick up the /dev/input/ devices (see 
/usr/local/share/X11/xorg.conf.d/10-evdev.conf if you have 
xf86-input-evdev installed), but it all depends on the device detection 
backend. If a device is not picked up by the backend, it won't even 
reach those "MatchDevicePath" rules. The udev backend on Linux sees all 
those /dev/input/ devices, but the devd backend currently ignores them. 
I believe there are some patches for the devd backend floating around, 
though. Hardcoding an input device in a Xorg configuration and not 
relying on the "MatchDevicePath" rules should work though.

I don't think you need a "complete" Xorg config with ServerLayout, 
Screen etc. in order to get input devices to work. Small "InputClass" 
sections in /usr/local/etc/X11/xorg.conf.d should be enough.

> In sum... how is this all meant to fit together?

FreeBSD still uses the 'old' input model, where each device type has its 
own node under /dev and its own xf86-input-* driver. Support for evdev 
style /dev/input/ nodes is not yet "plug'n'play" as they are unsupported 
by the devd backend. There is an in progress bug report about that here:

There are more evdev related input efforts ongoing:

  - The FreeBSD kernel actually supports creating evdev nodes for many 
input devices. Support is not activated in GENERIC per default, though.

  - There are libudev implementations for FreeBSD that are based on devd 
under the hood. While the devd backend for Xorg works fine, many other 
tools and libraries such as libinput and mesa are relying on the libudev 
API for device detection. It would be nice not having to develop devd 
backends for every such user. There is libudev-devd for example 
(https://github.com/wulf7/libudev-devd). There is also a port 
(devel/libudev-devd). I believe there is a Xorg port in the 
FreeBSDDesktop github repository that uses libudev-devd instead of the 
devd backend.

  - I wrote a userspace implementation of evdev 
(https://github.com/jiixyj/evdevfbsd) that 'translates' 
/dev/{atkbd,psm,sysmouse,uhid} devices to /dev/input/ nodes with cuse(3).

  - There is also a port of libinput to FreeBSD 
(https://github.com/jiixyj/libinput, ports tree: x11/libinput and 
x11-drivers/xf86-input-libinput). libinput needs evdev devices, though. 
They have to be created from the FreeBSD kernel evdev support or from 
userspace (webcamd, evdevfbsd). As far as I know, libinput+evdevfbsd is 
currently the only way to get smooth vertical and horizontal touchpad 
and trackpoint scrolling in Xorg on FreeBSD.


More information about the freebsd-x11 mailing list