Added udev rule for Microsoft X-Box One S pad

[lima-limon-inc]

The only caveat is the use of MODE="0664". It was the only way I could think of in order to be able to use the controller. When I plug it in, I get two files: /dev/input/js0 and /dev/input/event23. Without this udev rule, I did not have read privileges on /dev/input/event23. As soon as I made it readable manually, steam managed to recognize it (so did Xorg) and I was able to use it normally.

OS: Gentoo GNU/Linux

[chewi]

0664 shouldn't be necessary, regardless of the controller. On Gentoo, you either need to install the package with USE=acl or you need to be in the input group. It tells you this if you install the package without USE=acl. If you have enabled that and it still doesn't work then you might have some oddball setup.

[lima-limon-inc]

Thank you @chewi for the quick response. I just checked, these are the use flags games-util/game-device-udev-rules is installed with (using qlist) games-util/game-device-udev-rules-20220311::gentoo acl elogind -systemd I did try to add myself to the "input" group and it did work, however I have some security concerns about said group as it seemed a bit overkill to be able to read every /dev/input file just to use the controller (1, 2) . I thought of adding myself to a "games" or "joystick" group, and make those files owned by that group instead. I wanted a middle ground between "Unixness" and security (least privilege principal) . Do you think "games group" idea is viable?

1. https://www.reddit.com/r/linuxquestions/comments/bh4ex1/is_adding_a_user_to_input_group_secure/
2. https://bbs.archlinux.org/viewtopic.php?id=191593

[chewi]

You've enabled acl so you should not need to be in any group. You might also need CONFIG_TMPFS_POSIX_ACL enabled in your kernel. You should be able to do the following and see an entry for yourself:

$ getfacl -p /dev/input/event22
# file: /dev/input/event22
# owner: root
# group: input
user::rw-
user:chewi:rw-
group::rw-
mask::rw-
other::---

[lima-limon-inc]

Just to clarify: I do believe acl was set by default, possibly by the desktop profile

Regarding the kernel config, I am using sys-kernel/gentoo-kernel-bin. Do you know if that option is enabled in the binary? Maybe that's the issue

Btw, if I run that command, I get:

$ getfacl -p /dev/input/event23
# file: /dev/input/event23
# owner: root
# group: input
user::rw-
group::rw-
other::r--

I think the "other" read permission is because of my udev rule

[chewi]

I think it might be the issue that was faced in anyc/steam-overlay#326. This can happen when both CONFIG_FUSE_FS and CONFIG_INPUT_UINPUT are modules, which is the case for gentoo-kernel-bin. I'll raise this with the other devs.

[lima-limon-inc]

Thank you so much @chewi !! Would love to stay updated on that development. Any channel you recommend to do so?? Until then, my little hack will suffice :smile:

[chewi]

I've asked in #gentoo-dist-kernel on Libera.

[chewi]

They asked me what other distributions do. Good question. I checked Fedora and that has CONFIG_INPUT_UINPUT=m. I also tried gentoo-kernel-bin myself and didn't have any trouble. This might be because I'm using a Bluetooth controller rather than one that is plugged in at boot time. I'm also wondering what uinput has to do with it anyway, because these rules don't actually involve uinput. It's just that the other user said that reloading the module made it work. Which controller do you have? Is it wired or wireless?

[lima-limon-inc]

Hello @chewi, thanks for the follow up! My controller is wired. evtest says that it's input device name is "Microsoft X-Box One S pad".

I plug in my controller after I boot up my system. Should I boot it up with the controller already plugged in?

[smcv]

This rule shouldn't be needed on a properly-configured system.

I can't speak for Gentoo, but the way this works on (for example) Debian is that udev rules are meant to give the device 0660 permissions and the uaccess tag; and then there is some centralized infrastructure (normally systemd-logind, but in your case it would have to be elogind) that takes all devices with the uaccess tag, and applies a POSIX ACL similar to the one in https://github.com/ValveSoftware/steam-devices/pull/46#issuecomment-1537223291. Presumably Gentoo has similar infrastructure.

udev (possibly eudev in your case) should be putting the uaccess tag on all gamepads, including this one. In systemd's udev, this is done by the input_id builtin, with a few overrides in /lib/udev/hwdb.d/60-input-id.hwdb. If you're using eudev, I don't know how that differs.

Game controllers that are already plugged in at boot time, plugged in during runtime, or connected via Bluetooth should all work basically the same way. udev (and presumably eudev) handles devices that were already present at boot time by pretending they had been plugged in shortly after boot ("coldplug"), so they go through the same hotplug code paths.

[chewi]

Yeah, we give users the choice of 0660 + input group or uaccess + elogind/systemd ACLs. The latter works fine for me, although I only use Bluetooth controllers, so I'm never in a coldplug situation.

There's definitely something weird going on in this case, but I haven't been able to figure it out. I'm certainly not going to change our rules though, as I believe they are correct.

[lima-limon-inc]

Just to clarify my setup:

• Gentoo
• OpenRC
• gentoo-kernel-bin
• Microsoft X-Box One S pad wired controller

I don't have any other controller to compare its behavior against.

[lima-limon-inc]

Update: I just tried using a PS3 controller. I had the same issue. The same udev rule fixed it. Any clue wether it's a thing that happens on my machine alone or something related to gentoo kernel bin?