load uinput kernel module

[kparal]

Without the uinput module, "uaccess" udev tag is not applied to
/dev/uinput, which means neither Steam Controller nor any gamepad
handled by Steam Input is working (only in Steam menus, but not in
game). Steam complains:

Couldn't initialize virtual gamepad: Couldn't open /dev/uinput for
writing

Without this fix, the user has to be in the input group. With
this fix, it's no longer necessary and everything is working out of the
box.

---

Please note, I don't have a deep knowledge of udev and kernel modules and how this is supposed to be loaded the right way. But I can confirm this fixes Steam Controller or gamepads with Steam Input on my F29. I also believe this patch makes steam-controller-gamepad-emulation.patch unnecessary, but I can't vouch for it for any user.

[kparal]

CC @scaronni

[scaronni]

Everything is working fine here without the patch. The device is already loaded at startup and has already an ACL for the users on the console:

getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
user:slaanesh:rw-
group::rw-
mask::rw-
other::rw-

Anyway the uinput part is also tracked here (line 5):

ValveSoftware/steam-devices#1

I guess that patch covers basically everything for access on the console, if it's merged it should be fine. Would you like to chime in? I'm waiting until that is merged and then request the various changes for the Nvidia Shield controllers.

[scaronni]

The device is already loaded at startup and has already an ACL for the users on the console:
Not true, I just discovered it got loaded due to another component in a corner case.

Nevertheless, everything works fine for me. I have the following controllers and systems and they all work fine at the moment:

• Shield Portable, using SteamLink and the integrated controller
• Shield TV, using SteamLink with the 2015 controller
• Shield Controller 2015 attached to the computer (with rumble)
• xbox 360 controller clone attached to the computer (with rumble)
• SteamLink hardware with the wifi pairing to the Steam Controller
• SteamLink hardware with the xbox 360 controller
• Steam Controller connected with the wifi dongle to the computer
• Steam Controller connected with Bluetooth to the computer
• Steam Controller connected via Bluetooth to the phone for SteamLink

Is the controller you are using providing Xinput? Something like this when starting Steam:

Local Device Found
  type: 045e 028e
  path: sdl://0
  serial_number:  - 0
  Manufacturer: 
  Product:      XInput Controller
  Release:      2020
  Interface:    -1

[scaronni]

Just to be clear, when doing In-Home Streaming through the SteamLink app or hardware device, the remote controller appears as plugged in the USB ports of the host doing the streaming, so the udev rules for permissions need to apply to those as well. For example the Shield Controller is a standalone device and not a controller that you can plug in a PC:

https://github.com/rpmfusion/steam/blob/master/99-shield-controller.rules#L1-L2

[kparal]

Everything is working fine here without the patch. The device is already loaded at startup and has already an ACL for the users on the console:

I'm confused. What Fedora are you using? Is your system fully up-to-date? Is uinput module loaded for you automatically on system boot (or after Steam starts)? (see lsmod | grep uinput). Are you in the input group? (that shouldn't matter according to your output, but still)

Because for me, uinput module is not loaded automatically, and until I load it, I have the default permissions for /dev/uinput:

$ getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
group::rw-
other::---

Once I load it, my user immediately receives permissions to use it:

$ sudo modprobe uinput
$ getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
user:kparal:rw-
group::rw-
mask::rw-
other::---

I have to say I'm quite convinced this used to work before. I had Steam Controller for quite some time, I don't remember any issues. And I definitely wasn't a member of the input group. So my current theory is that:
a) permissions were handled differently back then (0666 perhaps?)
-or-
b) uinput module used to be loaded automatically (perhaps by a different program? or maybe it was directly compiled into the kernel instead of a module?)
-or-
c) uinput module wasn't needed (perhaps a recent change in systemd-udev?)

Anyway the uinput part is also tracked here (line 5):

ValveSoftware/steam-devices#1

This confuses me even more. steam-devices repo contains steam_input.rules with this content:

# This rule is necessary for gamepad emulation; make sure you replace 'pgriffais' with a group that the user that runs Steam belongs to
KERNEL=="uinput", MODE="0660", GROUP="pgriffais", OPTIONS+="static_node=uinput"

However, their latest tarball:
http://repo.steampowered.com/steam/pool/steam/s/steam/steam_1.0.0.59.tar.gz
has 60-steam-input.rules containing:

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess"

How is that possible? Why are those two files different (and distributed separately)?

Is the controller you are using providing Xinput?

I'm using Steam Controller with a wifi dongle. I also tested a Genius gamepad appearing as Xbox360 gamepad with Steam Input enabled. In both cases, both gamepad don't work in games at all until I modprobe uinput (but work in Steam big picture just fine).

[scaronni]

I'm confused. What Fedora are you using? Is your system fully up-to-date? Is uinput module loaded for you automatically on system boot (or after Steam starts)? (see lsmod | grep uinput). Are you in the input group? (that shouldn't matter according to your output, but still)

Fedora 29 with all the updates as of an hour ago. I'm not in the input group and uinput is not loaded at all.

$ id -a slaanesh
uid=1000(slaanesh) gid=1000(slaanesh) groups=1000(slaanesh),10(wheel),135(mock)

Just to be sure I restarted and rechecked everything (computer has been running for a few days). Same as before, no uinput module, streaming (Tomb Raider, Fez) and plugging stuff in works.

Because for me, uinput module is not loaded automatically, and until I load it, only root can access /dev/uinput. Once I load it, my user immediately receives permissions to use it.

Correct, same here:

$ getfacl /dev/uinput 
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
group::rw-
other::rw-

But still everything works for me :/

I have to say I'm quite convinced this used to work before. I had Steam Controller for quite some time, I don't remember any issues. And I definitely wasn't a member of the input group. So my current theory is that:
a) permissions were handled differently back then (0666 perhaps?)

Not according to what I see, but I'm not 100% certain

b) uinput module used to be loaded automatically (perhaps by a different program? or maybe it was directly compiled into the kernel instead of a module?)

It seems not according to git commits:

https://src.fedoraproject.org/rpms/kernel/commits/f29

c) uinput module wasn't needed (perhaps a recent change in systemd-udev?)

Still, I don't need it :/

How is that possible? Why are those two files different (and distributed separately)?

We should ask Valve :( Maybe it did work for you with Steam 1.0.0.56 and different udev rules?

I'm using Steam Controller with a wifi dongle. I also tested a Genius gamepad appearing as Xbox360 gamepad with Steam Input enabled.

Same here, both work fine as is. Also my Xbox360 clone controllers have a switch in the back to turn off Xinput, but still they work the same and make no difference at all.

In both cases, both gamepad don't work in games at all until I modprobe uinput (but work in Steam big picture just fine).

When this was happening to me (it happens for example when streaming with SteamLink) I had to adjust the permissions in the Steam udev rules (hence my last PR to the Shield Controller config - cyndis/shield-controller-config#4) to loose access restrictions. Based on this, the PR that is open in the Steam udev rules repository is a better approach.

I'm confused.

[kparal]

My /dev/uinput has:

other::---

while your has:

other::rw-

That's the reason why you don't need uinput kernel module (to make "uaccess" work). You already have the file world writable.

Some udev rule must be adjusting your /dev/input permissions to world writable. Can you show me your output of:

$ grep -r uinput /usr/lib/udev/ /etc/udev/ /run/udev/
/usr/lib/udev/rules.d/60-steam-input.rules:KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess"
/usr/lib/udev/rules.d/60-steam-input.rules:KERNEL=="uinput", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput"

When this was happening to me (it happens for example when streaming with SteamLink) I had to adjust the permissions in the Steam udev rules (hence my last PR to the Shield Controller config - cyndis/shield-controller-config#4) to loose access restrictions.

I don't understand udev rules too much. But IIUIC that patch seems to adjust just the input device for Nvidia Shield, and should not affect /dev/uinput. So the loosened permissions should be coming from elsewhere. But just in case, can you test the behavior when you keep just the stable steam package installed and remove any additional udev rules you might have that could affect this?

[scaronni]

That's the reason why you don't need uinput kernel module (to make "uaccess" work). You already have the file world writable.

Good catch! I have the same rules but mode 0666 in them while you have 0660 in a local change, but the file is marked as config so it's not updated when updating the steam package. Can you check that if you change it the same way on your system it works without loading the uinput module?

#  grep -r uinput /usr/lib/udev/ /etc/udev/ /run/udev/
/usr/lib/udev/rules.d/60-steam-input.rules:KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess"
/usr/lib/udev/rules.d/60-steam-input.rules:KERNEL=="uinput", MODE="0666", GROUP="input", OPTIONS+="static_node=uinput"

If it works for you I will just push the updated udev patch. The better option to not have 666 on the pad device files is the PR in Valve's repository, but being completely different I would skip it for now.

I don't understand udev rules too much. But IIUIC that patch seems to adjust just the input device for Nvidia Shield, and should not affect /dev/uinput.

Correct, but it's just an example. Without setting it to "666", input worked for me on Steam Big Picture while streaming but not in the games that were streaming.

[scaronni]

I've noticed something else... The mode 660 is in the patch for the gamepad emulation, and the patch is applied at the end of the file.

Apparently the udev rules file changed substantially and at the beginning of the file there is this:

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess"

Can you remove the last line of the file and just check if this is enough for your controller?

[scaronni]

Made a test here with:

• MODE="0660", TAG+="uaccess" for every controller
• No gamepad emulation line at the end
• TAG+="uaccess" on the uinput line

Everything seems to be fine! I'll update the package if also your feedback is fine.

[scaronni]

OK, I'll wait for feedback on that comment before proceeding. The final udev rules file should look like this (uaccess everywhere):

# Valve USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0660", TAG+="uaccess"

# DualShock 4 over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", MODE="0660", TAG+="uaccess"

# DualShock 4 wireless adapter over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ba0", MODE="0660", TAG+="uaccess"

# DualShock 4 Slim over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", MODE="0660", TAG+="uaccess"

# DualShock 4 over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:05C4*", MODE="0660", TAG+="uaccess"

# DualShock 4 Slim over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:09CC*", MODE="0660", TAG+="uaccess"

# Nintendo Switch Pro Controller over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", MODE="0660", TAG+="uaccess"

# Nintendo Switch Pro Controller over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*057E:2009*", MODE="0660", TAG+="uaccess"

# Nacon PS4 Revolution Pro Controller
KERNEL=="hidraw*", ATTRS{idVendor}=="146b", ATTRS{idProduct}=="0d01", MODE="0660", TAG+="uaccess"

# Razer Raiju PS4 Controller
KERNEL=="hidraw*", ATTRS{idVendor}=="1532", ATTRS{idProduct}=="1000", MODE="0660", TAG+="uaccess"

# Razer Panthera Arcade Stick
KERNEL=="hidraw*", ATTRS{idVendor}=="1532", ATTRS{idProduct}=="0401", MODE="0660", TAG+="uaccess"

# Mad Catz - Street Fighter V Arcade FightPad PRO
KERNEL=="hidraw*", ATTRS{idVendor}=="0738", ATTRS{idProduct}=="8250", MODE="0660", TAG+="uaccess"

# Mad Catz - Street Fighter V Arcade FightStick TE S+
KERNEL=="hidraw*", ATTRS{idVendor}=="0738", ATTRS{idProduct}=="8384", MODE="0660", TAG+="uaccess"

# EMiO Elite Controller for PS4
KERNEL=="hidraw*", ATTRS{idVendor}=="0c12", ATTRS{idProduct}=="1cf6", MODE="0660", TAG+="uaccess"

# HORI RAP4
KERNEL=="hidraw*", ATTRS{idVendor}=="0f0d", ATTRS{idProduct}=="008a", MODE="0660", TAG+="uaccess"

# HORIPAD 4 FPS
KERNEL=="hidraw*", ATTRS{idVendor}=="0f0d", ATTRS{idProduct}=="0055", MODE="0660", TAG+="uaccess"

# HORIPAD 4 FPS Plus
KERNEL=="hidraw*", ATTRS{idVendor}=="0f0d", ATTRS{idProduct}=="0066", MODE="0660", TAG+="uaccess"

# Armor Armor 3 Pad PS4
KERNEL=="hidraw*", ATTRS{idVendor}=="0c12", ATTRS{idProduct}=="0e10", MODE="0660", TAG+="uaccess"

# STRIKEPAD PS4 Grip Add-on
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c5", MODE="0660", TAG+="uaccess"

[kparal]

I've created ValveSoftware/steam-devices#2 to ask Valve to sync the udev rules so that there's less confusion.

As far as I can see, the MODE="0666" must be your local modification, because MODE="0660" is in the original patch:
https://github.com/rpmfusion/steam/blob/master/steam-controller-gamepad-emulation.patch
(and I don't see the udev files to be marked as config files in the spec file, so I have no idea why you don't have the same version).

However, rewriting it to MODE="0666" fixes everything for me, because the file is world writable. But I'd be afraid of the security implications. Giving 666 to a gamepad might not be that bad, but allowing anyone (even remote users/services) to create arbitrary virtual devices through uinput might be a big problem. So I'd rather avoid that solution.

Can you remove the last line of the file and just check if this is enough for your controller?

That didn't help. But after reading ValveSoftware/steam-for-linux#4794 I think i found the ultimate solution:

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

This line fixes everything for me. The OPTIONS+="static_node=uinput" part makes sure the uinput module is dynamically loaded on use, and makes my PR no longer necessary. It also makes the steam-controller-gamepad-emulation.patch no longer necessary.

Can you please try to adjust the /usr/lib/udev/rules.d/60-steam-input.rules as specified above and also remove the last line:

KERNEL=="uinput", MODE="0666", GROUP="input", OPTIONS+="static_node=uinput"

and see whether it works well for you? (I always reboot after changing udev files, it's the most reliable way to test). It works perfectly for me.

[kparal]

OK, I'll wait for feedback on that comment before proceeding. The final udev rules file should look like this (uaccess everywhere):

I see we arrived at the same solution simultaneously :) I'll test your file and let you know. I'm not sure we need to give uaccess to everything (that's a lot of patching), but perhaps it's a bit more secure.

[scaronni]

Based on their last comment (I did not know that Timothee Besset was working for Valve and taking care of udev!) it seems patching is the way to go... I will make a build with the patch, if the file will change (I'm tracking the beta client) I will update accordingly.

I'm not sure we need to give uaccess to everything (that's a lot of patching), but perhaps it's a bit more secure.

I prefer uaccess everywhere, to be honest. As you said is more secure.
It's been a while since I looked at the various udev rules in detail...

[kparal]

I can confirm your new file is working perfectly for me. Once there's a new rpm build with it, I'll be happy to test it.

[kparal]

Closing this PR, superseded by bcd7118.

[scaronni]

Just did the build, it also contains a change for In-Home Streaming firewall rules, since firewalld 0.6.2 (Fedora 29) they are contained in the firewalld package itself and I didn't know it.

http://koji.rpmfusion.org/koji/packageinfo?packageID=413

Btw:

$ rpm -ql systemd-udev | grep uaccess
/usr/lib/udev/rules.d/70-uaccess.rules

Thanks for debugging it! Good night.

[kparal]

I think /usr/lib/udev/rules.d/99-shield-controller.rules will not work properly, because anything using uaccess must be before /usr/lib/udev/rules.d/73-seat-late.rules. See ValveSoftware/steam-for-linux#5169. Perhaps change it to 60-* as well?

[kparal]

steam-1.0.0.59-6.fc29 works fine for me (Steam Controller)

[scaronni]

I think /usr/lib/udev/rules.d/99-shield-controller.rules will not work properly, because anything using uaccess must be before /usr/lib/udev/rules.d/73-seat-late.rules. See ValveSoftware/steam-for-linux#5169. Perhaps change it to 60-* as well?

I made a test before pushing the commit with the Shield Tablet / Controller and it was working fine, but I will double check it, thanks for the input.

Plan is to make a PR if they align the repository with the tarball ruleset with all the changes, including the Shield Portable, Shield Controller 2015 and the Bluetooth 2017 one.