The bug: the Mir-kiosk snap is failing to detect new input devices. Those devices plugged in when starting the snap are detected, it is only newly added devices which are not.
I can reproduce on Ubuntu Core and Classic. I’m using Classic for ease of debugging.
Steps to repro:
sudo snap install mir-kiosk --edge --devmode
Mir will auto-start. Note: Mir will try to use VT1, which may collide with GDM. Workaround is to edit /snap/mir-kiosk/current/bin/run-miral and specify a different VT.
Plug in a new USB mouse and wiggle it. Mir’s mouse cursor should move, but it doesn’t.
Facts I’ve learned
A. After digging into Mir/libinput/udev/evdev, I’ve learned the udev is detecting the new device, libinput is getting evdev to open the new input device node (/dev/input/event*) but that open fails. That’s the reason Mir fails to use the new mouse.
To see this, run
sudo gdb -p $(pidof miral-kiosk) after Mir has started up, and break on the open syscall
> catch syscall open
If you plug in a device, this will catch on trying to open the input device node for the newly added USB mouse. Here’s a cleaned up backtrace with symbols: http://pastebin.ubuntu.com/25918597/, with the path it is attempting to open printed on frame 4. Enter
finish to have that method complete, and
p $rax to print the return value.
p errno to get the error code:
Run till exit from #0 0x00007f564fe9802d in open64 () at ../sysdeps/unix/syscall-template.S:84
Thread 4 "Mir/Input Reade" hit Catchpoint 1 (returned from syscall open), 0x00007f564fe9802d in open64 () at ../sysdeps/unix/syscall-template.S:84
84 in ../sysdeps/unix/syscall-template.S
(gdb) p $eax
$1 = -1 // the FD returned is invalid
(gdb) p errno
$2 = 2 // ENOENT, aka "No such file or directory."
I don’t understand why, as I see that file just fine.
$ ls -l /dev/input/event5
crw-rw---- 1 root input 13, 69 Nov 8 16:07 /dev/input/event5
B. To compare with a working Mir, this command will work:
sudo LD_LIBRARY_PATH=/snap/mir-kiosk/current/usr/lib/x86_64-linux-gnu:/snap/mir-libs/current/mirlibs0/usr/lib/x86_64-linux-gnu/:/snap/mir-kiosk/current/usr/lib/x86_64-linux-gnu/mesa-egl MIR_SERVER_PLATFORM_PATH=/snap/mir-kiosk/current/usr/lib/x86_64-linux-gnu/mir/server-platform/ /snap/mir-kiosk/current/usr/bin/miral-kiosk
Doing the same test as above, you should see that the open syscall above will succeed, and the new mouse will be recognised by Mir. (ofc they’re not identical comparisons, as this isn’t using the core libs from snap core, but locally available ones)
C. dmesg or sudo /snap/bin/snappy-debug.security scanlog isn’t giving me anything, but as I’m using devmode, I didn’t expect much help there.
D. The mir interface does allow access to /dev/input/event[0-9]
E. Using strace, I do not to see Mir doing the open syscall at all. Yet GDB can - presumably it intercepts at the glibc level, but still, what??
So I’m once again confused why Mir is unable to open the device node for the newly added USB device. I’ve tried adding the hardware-observer plug to no effect.
Suggestions/ideas would be appreciated.