User not able to use/detect uinput device
pastaq opened this issue · 4 comments
I have a project that uses python-evdev to create a virtual xbox controller for the Aya Neo line of handheld devices so that the keyboard buttons on the device can be mapped to controller events. I have received reports from users in different OS's that the device isn't detectable by the user. In my normal testing environment is has been the case that the user is able to use the device. However, when switching to the latest build I also began to experience the issue. I haven't been able to determine what the root cause of this change in behavior is. For reference, the OS i usually use is ChimeraOS. In v33 the evtest program shows the virtual device when run by the user. In v34 it does not, and steam is not able to use the device.
One difference I did notice is the ACL does not seem to be transferred to the UInput device in the latest build.
v33
[gamer@chimeraos ~]$ getfacl /dev/input/event13
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event13
# owner: root
# group: input
user::rw-
user:gamer:rw-
group::rw-
mask::rw-
other::---
v34
[gamer@chimeraos input]$ getfacl /dev/input/event13
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event14
# owner: root
# group: input
user::rw-
group::rw-
other::---
Setting the ACL after the fact does not fix the problem however. I am a bit lost on where to go from here. UDEV rules were not changed from v33 to v34, though systemd was upgraded from v 250 to v251. Any advice on solving this problem would be appreciated. Thank you.
Here is a link to my project's implementation: https://github.com/ShadowBlip/aya-neo-fixes/blob/main/neo-controller.py
Here is the build difference from the two versions:
--- build_info.txt 2022-05-23 22:11:12.857801806 -0400
+++ build_info(1).txt 2022-05-23 22:11:15.531107132 -0400
@@ -1,4 +1,4 @@
-chimeraos-33_7dcb575
+chimeraos-34_2a669bc
accountsservice 22.08.8-2
acl 2.3.1-2
@@ -23,7 +23,7 @@
attr 2.5.1-2
audit 3.0.8-1
avahi 0.8+22+gfd482a7-3
-aya-neo-fixes-git 22.05.r48.7603ccd-1
+aya-neo-fixes-git 22.05.r49.f0856d4-1
base 2-2
bash 5.1.016-1
bc 1.07.1-4
@@ -71,15 +71,15 @@
dbus-python 1.2.18-3
dconf 0.40.0-1
desktop-file-utils 0.26-2
-device-mapper 2.03.15-1
+device-mapper 2.03.16-1
diffutils 3.8-1
ding-libs 0.6.1-4
dkms 3.0.3-1
dmraid 1.0.0.rc16.3-13
dnsmasq 2.86-1
dnssec-anchors 20190629-3
-dolphin-emu-git 5.0.r16479.g243df970ff-1
-dolphin-emu-nogui-git 5.0.r16479.g243df970ff-1
+dolphin-emu-git 5.0.r16510.g1e64d21d40-1
+dolphin-emu-nogui-git 5.0.r16510.g1e64d21d40-1
dosbox 0.74.3-2
dosfstools 4.2-2
double-conversion 3.2.0-1
@@ -101,7 +101,7 @@
freeglut 3.2.2-2
freetype2 2.12.1-1
fribidi 1.0.12-1
-frzr 0.10.1-1
+frzr 0.10.2-1
fuse-common 3.11.0-1
fuse2 2.9.9-4
fuse3 3.11.0-1
@@ -126,7 +126,7 @@
glibc 2.35-5
glslang 11.9.0-1
glu 9.0.2-3
-gmp 6.2.1-1
+gmp 6.2.1-2
gnupg 2.2.35-2
gnutls 3.7.5-1
gobject-introspection-runtime 1.72.0-1
@@ -267,8 +267,8 @@
lib32-pcre 8.45-1
lib32-pipewire 1:0.3.51-1
lib32-readline 8.1.002-1
-lib32-sqlite 3.38.3-1
-lib32-systemd 250.5-1
+lib32-sqlite 3.38.5-1
+lib32-systemd 251-1
lib32-util-linux 2.38-1
lib32-vulkan-icd-loader 1.3.213-1
lib32-vulkan-intel 22.0.4-1
@@ -312,9 +312,8 @@
libglvnd 1.4.0-2
libgpg-error 1.45-1
libgudev 237-2
-libibus 1.5.26-2
libical 3.0.14-3
-libice 1.0.10-3
+libice 1.0.10-4:q:
libidn11 1.33-2
libidn2 2.3.2-1
libiec61883 1.2.0-6
@@ -349,7 +348,7 @@
libomxil-bellagio 0.9.3-3
libp11-kit 0.24.1-1
libpcap 1.10.1-2
-libpciaccess 0.16-2
+libpciaccess 0.16-3
libpgm 5.3.128-2
libpng 1.6.37-3
libproxy 0.4.17-6
@@ -427,37 +426,37 @@
libwebp 1.2.2-1
libwpe 1.12.0-2
libx11 1.8-1
-libxau 1.0.9-3
+libxau 1.0.9-4
libxcb 1.15-1
-libxcomposite 0.4.5-3
+libxcomposite 0.4.5-4
libxcrypt 4.4.28-2
libxcursor 1.2.1-1
libxcvt 0.1.1-1
-libxdamage 1.1.5-3
-libxdmcp 1.1.3-3
-libxext 1.3.4-3
+libxdamage 1.1.5-4
+libxdmcp 1.1.3-4
+libxext 1.3.4-4
libxfixes 6.0.0-1
libxfont2 2.0.5-1
libxft 2.3.4-1
libxi 1.8-1
libxinerama 1.1.4-4
-libxkbcommon 1.4.0-1
-libxkbcommon-x11 1.4.0-1
-libxkbfile 1.1.0-2
+libxkbcommon 1.4.1-1
+libxkbcommon-x11 1.4.1-1
+libxkbfile 1.1.0-3
libxklavier 5.4-3
libxml2 2.9.14-1
-libxmu 1.1.3-2
-libxrandr 1.5.2-3
-libxrender 0.9.10-4
+libxmu 1.1.3-3
+libxrandr 1.5.2-4
+libxrender 0.9.10-5
libxres 1.2.1-1
libxshmfence 1.3-3
libxslt 1.1.35-1
libxss 1.2.3-4
libxt 1.2.1-1
-libxtst 1.2.3-4
-libxv 1.0.11-4
+libxtst 1.2.3-5
+libxv 1.0.11-5
libxvmc 1.0.13-1
-libxxf86vm 1.1.4-4
+libxxf86vm 1.1.4-5
libyaml 0.2.5-1
libzip 1.8.0-1
licenses 20220125-1
@@ -477,7 +476,7 @@
lshw B.02.19.2-4
lsof 4.95.0-1
lv2 1.18.2-1
-lvm2 2.03.15-1
+lvm2 2.03.16-1
lz4 1:1.9.3-2
lzo 2.10-3
make 4.3-3
@@ -616,16 +615,16 @@
retroarch 1.10.3-1
retroarch-autoconfig-udev-git r2034.3ef025f-1
rpcbind 1.2.6-2
-rpcs3-git 0.0.22.13632.1be36fe6a-1
+rpcs3-git 0.0.22.13640.e68ffdbc8-1
rsync 3.2.4-1
rtkit 0.13-1
-rtl8812au-dkms-git 5.13.6.r118.gfb87d6e-1
-rtl8814au-dkms-git 5.8.5.1.r138.g9bf80cf-1
-rtl88x2bu-dkms-git 5.13.1.r161.cc37592-1
+rtl8812au-dkms-git 5.13.6.r119.gedb17ca-1
+rtl8814au-dkms-git 5.8.5.1.r139.g687f05c-1
+rtl88x2bu-dkms-git 5.13.1.r162.40fef7d-1
rtw89-dkms-git 1:r176.da9d01e-1
sbc 1.5-2
sdl12-compat 1.2.52-2
-sdl2 2.0.22-1
+sdl2 2.0.22-2
sdl2_image 2.0.5-2
sdl2_mixer 2.0.4-7
sdl2_ttf 2.0.18-1
@@ -662,9 +661,9 @@
sxhkd 0.6.2-2
sysfsutils 2.1.1-1
syslinux 6.04.pre2.r11.gbf6db5b4-3
-systemd 250.5-1
-systemd-libs 250.5-1
-systemd-sysvcompat 250.5-1
+systemd 251-1
+systemd-libs 251-1
+systemd-sysvcompat 251-1
talloc 2.3.3-3
tar 1.34-1
tcl 8.6.12-3
@@ -726,8 +725,8 @@
xkeyboard-config 2.35.1-1
xone-dkms 0.2-1
xorg-fonts-encodings 1.0.5-2
-xorg-server 21.1.3-6
-xorg-server-common 21.1.3-6
+xorg-server 21.1.3-7
+xorg-server-common 21.1.3-7
xorg-setxkbmap 1.3.3-1
xorg-xinput 1.6.3-3
xorg-xkbcomp 1.4.5-1
In my normal testing environment is has been the case that the user is able to use the device.
Usually from what I have seen so far regular users don't have access to the devices. I guess to prevent keyloggers. I usually do sudo evtest.
I haven't been able to determine what the root cause of this change in behavior is.
I'm not aware of anything, can't tell.
steam is not able to use the device
I wonder how steam usually accesses controllers. I would have thought that there must be some sort of interface between the display server and steam. Just like how X11 accesses keyboards, translates the events to symbols and then provides those to all the applications.
Maybe you could try to figure out if it makes a difference if wayland or X11 is used.
I guess your applications is running as root? You could try to grant the o+r permission to the created uinput automatically. Since there doesn't seem to be any sensitive information in there, just gamepad events, I guess this change would not be critical for security.
Usually from what I have seen so far regular users don't have access to the devices. I guess to prevent keyloggers. I usually do
sudo evtest.
Up until whatever recently changed I was able to see both the xbox360 controller and the virtual controller created from that device as user, and only needed sudo to see things like keyboards, lid switches, etc.
I wonder how steam usually accesses controllers. I would have thought that there must be some sort of interface between the display server and steam. Just like how X11 accesses keyboards, translates the events to symbols and then provides those to all the applications.
Presumably there is some translation layer. Steam can see keyboards after all.
Maybe you could try to figure out if it makes a difference if wayland or X11 is used.
I will verify if the behavior has also affected X11 as I have only tested it in wayland. Previously it was working in both however.
I guess your applications is running as root? You could try to grant the o+r permission to the created uinput automatically. Since there doesn't seem to be any sensitive information in there, just gamepad events, I guess this change would not be critical for security.
Is there a way to copy/change ACL's when creating a new uinput device through python? Manually setting this didn't seem to solve the problem and could be a symptom instead of a cause.
I also have ACLs set on my uinput devices by default by the way
Is there a way to copy/change ACL's when creating a new uinput device through python?
couldn't find anything. You could use subprocess.Popen to call setfacl of course, though it's probably not very pretty.
Maybe those are related: ValveSoftware/steam-for-linux#4794, pwr-Solaar/Solaar#1607
Usually from what I have seen so far regular users don't have access to the devices
I completely missed that this doesn't seem to apply to uinputs, good to know
Thank you! After reading that second link and then creating some udev rules I was able to get everything working as expected.
In case someone else has the same problem, place the following in /etc/udev/rules.d:
60-{custom-device-name}.rules (change name and xxxx to expected values)
KERNEL=="py-evdev-uinput", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="xxxx", MODE="0660", TAG+="uaccess", ENV{ID_INPUT_JOYSTICK}="1"