Hi, I have eglfs Qt app snapped. What interface should I use to make mouse/keyboard available?
I20210209 22:13:27.703675 2137 main.cpp:27] evdevkeyboard: Using device discovery
I20210209 22:13:27.703855 2137 main.cpp:27] static device discovery for type QFlags<QDeviceDiscovery::QDeviceType>(Device_Keyboard)
W20210209 22:13:27.704229 2137 main.cpp:30] Device discovery cannot open device "/dev/input/mice"
I20210209 22:13:27.704282 2137 main.cpp:27] Found matching devices ()
I20210209 22:13:27.704370 2137 main.cpp:27] evdevmouse: Using device discovery
I20210209 22:13:27.704438 2137 main.cpp:27] static device discovery for type QFlags<QDeviceDiscovery::QDeviceType>(Device_Mouse|Device_Touchpad)
W20210209 22:13:27.704628 2137 main.cpp:30] Device discovery cannot open device "/dev/input/mice"
I20210209 22:13:27.704674 2137 main.cpp:27] Found matching devices ()
I20210209 22:13:27.704739 2137 main.cpp:27] evdevtouch: Using device discovery
I20210209 22:13:27.704794 2137 main.cpp:27] static device discovery for type QFlags<QDeviceDiscovery::QDeviceType>(Device_Touchpad|Device_Touchscreen)
W20210209 22:13:27.704952 2137 main.cpp:30] Device discovery cannot open device "/dev/input/mice"
I20210209 22:13:27.704994 2137 main.cpp:27] Found matching devices ()
I see that mir/wayland give access to that, but I am a bit confused about how to use them (and that seems to be an overkill anyhow, it gives a lot of other access as well).
I added mir to plugs, but I am not sure how to actually connect it since mir is not a part of the core snap.
sadly there is no interface providing that access standalone, x11, wayland and mir all include /dev/input though (i have a similar problem with https://snapcraft.io/kodi-pi-standalone where i run kodi as GBM app directly on the hardware). Effectively we will need a new devinput interface (i talked to @ijohnson about this before sadly it needs some tinkering to even collect the right denial messages, since /dev/input access is completely quietened in apparmor)
i guess for now your short term solution might be to add a mir slot to your snap (which is the least permissive of x11, wayland and mir) and make a request in the store-requests category to get this slot granted … (just having the slot seems to be enough, no need to have a plug)
AFAICT it’s not apparmor which is denying this, it’s the devices cgroup not allowing access to that, which is not logged anywhere unfortunately. Are you able to just try in devmode where we turn off the devices cgroup entirely (and thus AppArmor would still be in the picture, but just with ALLOW messages)?
IIRC just the toplevel slot definition allowed the app to get input events (i think the slot definition simply grants the whole set of permissions to all of the snap (which is most likely also the reason you have to ask for having the slot granted))
sure, if you can give me the secret handshake instructions i will capture them
(though i guess just cloning the mir interface and ripping out all wayland/graphics bits would also work (i just didnt find the time yet to prepare a PR else i would have gone that route already))
Unfortunately, I can’t run in devmode, after some change it stopped working because it actually fails to access vchiq node while in devmode unlike the confined.
And keyboard detection seems to happen after so I don’t see any logs with the following command:
sudo sysctl -w kernel.printk_ratelimit=0 ; journalctl --follow |grep audit|grep apparmor|grep snap.screenly-client|grep /dev/input
If the snap can’t work in devmode, one can try the following:
Install the snap version with the mir slot and no devmode
Edit the the profile for the main command(s) /var/lib/snapd/apparmor/profiles/snap.<snap-name>.<command>
If it’s using the mir slot there should be a line: /dev/input/* rw, replace it with audit allow /dev/input/* rw,
reload the profile with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.<snap-name>.<command>
now run the relevant commands, things should still run now because it’s not devmode, but because of the audit accesses to any /dev/input/* should hopefully appear in the log under the patterns described before
Thanks for providing the information. It seems that either a new privileged raw-input (similar to raw-usb) interface that grants access to /dev/input/* and also udev events, or something like a privileged new device-input (similar to device-buttons) interface, would cover this use case.
(though i guess just cloning the mir interface and ripping out all wayland/graphics bits would also work (i just didnt find the time yet to prepare a PR else i would have gone that route already))