Comment 0 for bug 1237784

Mir currently uses an inotify watch on /dev/input/ to detect hotplugged input events. That already led to race conditions like bug 1233944 and is generally not very robust. The canonical way to enumerate (for coldplugging at start) and get change notifications for (hotplugging events) hardware is to use uevents, which have a rather convenient client-side library "libudev". These are race free (i. e. you only get told after all udev rules got applied), very efficient (you only get wakeups if something actually changed), and easier to use as you get a lot of the actual information of the piece of hardware "for free" (i. e. already in the udev_device object).

http://www.freedesktop.org/software/systemd/libudev/ is the reference documentation (also in libudev-dev); you want the udev_monitor_* bits for receiving events, the enumerate bits for detecting devices at startup (coldplug), and udev_device_* for querying for attributes and properties (grep "udevadm info --export-db" for "input" about available properties, such as ID_INPUT_KEYBOARD=1).

http://www.signal11.us/oss/udev/ has an useful intro and example how to use this. I'm also happy to help you with reviewing code or answering any questions you have about the API.

The porting should not actually be too bad. Just like inotify, with pure libudev the monitor gives you an fd you select() on in the main loop, and if there's an event you just grab it with receive_device(). The libgudev library provides a very elegant integration into GLib main loops where you just connect the "uevent" signal to your handler, but I suppose Mir does not want to use this.