Comment 11 for bug 1233944

Pardon my ignorance. "touch ~/.display-mir" enables Mir, and there is no such thing as a "Mir server process". It's all going through libraries only, so on the Ubuntu side unity8 and other user process directly access input devices in /dev/input/events/* (through its bundled copy of the Android input stack). This only works because the phablet user is in the android_input group (yuck big security hole!)

According to Daniel d'Andrada, Mir does not listen to uevents to pick up new input devices, but uses an inotify watch on /dev/input/ (!). So what likely happens is the following:

(1) a new input device gets created by uinput, or an USB/bluetooth hotplug event
(2) /dev/input/eventX gets created, with the usual initial root:root 600 permissions
(3) inotify event gets sent to Mir, which tries to open it and can't
(4) udev applies its rules and changes mode to root:android_input 0600
(5) Mir does not try to re-open the device after an initial failure, and thus can't see the device

So as an immediate hotfix I suggest that Mir needs to re-try opening the device again after it sees a *change* of an existing device.

But I strongly recommend dropping the inotify approach (which really isn't meant for this kind of thing) and use the much more efficient and race free uevent handling like everything else that handles hardware. With libudev you get the add/change events after rules are processed (thus the devices have the correct permissions and properties when you receive the event), and you avoid wakeups on every change in /dev/input, as you can tell libudev to only call back on events for a particular subsystem ("input" in that case).