Arch Linux

Hubro

Member

Registered: 2019-03-09

Posts: 32

[SOLVED] Why don't the udev rules in the multilib/steam package work?

If I plug in my Steam Controller USB receiver and reboot my PC, my hidraw files look like this:

➜ ls -lh /dev | grep -i hidraw            
crw-------  1 root  root   238,   0 Aug 31 15:01 hidraw0
crw-rw----+ 1 root  root   238,   1 Aug 31 15:01 hidraw1
crw-------  1 root  root   238,  10 Aug 31 15:01 hidraw10
crw-------  1 root  root   238,  11 Aug 31 15:01 hidraw11
crw-------  1 root  root   238,  12 Aug 31 15:01 hidraw12
crw-------  1 root  root   238,  13 Aug 31 15:01 hidraw13
crw-------  1 root  root   238,  14 Aug 31 15:01 hidraw14
crw-------  1 root  root   238,  15 Aug 31 15:01 hidraw15
crw-------  1 root  root   238,  16 Aug 31 15:01 hidraw16
crw-rw----+ 1 root  root   238,   2 Aug 31 15:01 hidraw2
crw-rw----+ 1 root  root   238,   3 Aug 31 15:01 hidraw3
crw-rw----+ 1 root  root   238,   4 Aug 31 15:01 hidraw4
crw-rw----+ 1 root  root   238,   5 Aug 31 15:01 hidraw5
crw-------  1 root  root   238,   6 Aug 31 15:01 hidraw6
crw-------  1 root  root   238,   7 Aug 31 15:01 hidraw7
crw-------  1 root  root   238,   8 Aug 31 15:01 hidraw8
crw-------  1 root  root   238,   9 Aug 31 15:01 hidraw9

The Steam Controller is hidraw 2-5, so the udev rules appear to do *something*.

The extended file attributes look like this:

➜ getfattr -d -m ".*" /dev/hidraw2
getfattr: Removing leading '/' from absolute path names
# file: dev/hidraw2
system.posix_acl_access=0sAgAAAAEABgD/////BAAGAP////8QAAYA/////yAAAAD/////

Cool! This doesn't appear to actually do anything though. If I launch Steam, go to Big Picture Mode and list my controllers, it says "No controllers detected".

Additionally Steam's terminal output includes this, though I'm not sure if it's related:

No cached sticky mapping in Get*ActionHandle. Native Steam Controller support won’t work.

If I simply give myself read/write permissions to the hidraw files:

➜ sudo chmod o+rw /dev/hidraw2 /dev/hidraw3 /dev/hidraw4 /dev/hidraw5
➜ ls -lh /dev | grep -i hidraw
crw-------  1 root  root   238,   0 Aug 31 15:01 hidraw0
crw-rw----+ 1 root  root   238,   1 Aug 31 15:01 hidraw1
crw-------  1 root  root   238,  10 Aug 31 15:01 hidraw10
crw-------  1 root  root   238,  11 Aug 31 15:01 hidraw11
crw-------  1 root  root   238,  12 Aug 31 15:01 hidraw12
crw-------  1 root  root   238,  13 Aug 31 15:01 hidraw13
crw-------  1 root  root   238,  14 Aug 31 15:01 hidraw14
crw-------  1 root  root   238,  15 Aug 31 15:01 hidraw15
crw-------  1 root  root   238,  16 Aug 31 15:01 hidraw16
crw-rw-rw-+ 1 root  root   238,   2 Aug 31 15:01 hidraw2
crw-rw-rw-+ 1 root  root   238,   3 Aug 31 15:01 hidraw3
crw-rw-rw-+ 1 root  root   238,   4 Aug 31 15:01 hidraw4
crw-rw-rw-+ 1 root  root   238,   5 Aug 31 15:01 hidraw5
crw-------  1 root  root   238,   6 Aug 31 15:01 hidraw6
crw-------  1 root  root   238,   7 Aug 31 15:01 hidraw7
crw-------  1 root  root   238,   8 Aug 31 15:01 hidraw8
crw-------  1 root  root   238,   9 Aug 31 15:01 hidraw9

And restart Steam, now I have native Steam Controller support. It applies my desktop mapping, the controller shows up under Big Picture and can be configured, and everything appears to work just like under Windows.

However, any mappings for the Steam Controller that emulate a controller don't work. If I map the right touch pad to "Mouse", it works perfectly, but if I map the left thumb stick to the left thumbstick of a controller, it does nothing. If I map the "A" button on the Steam Controller to the "A" gamepad button, it also does nothing, etc. Only mappings to mouse/keyboard work.

I assume this is because of more permission errors (i.e. Steam can't emulate a controller because of permission errors.)

I just noticed another error in Steam's terminal output while writing this question:

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

I gave myself full read/write access to "/dev/uinput" the same way I did with the hidraw devices and now controller mappings also work ingame.

I don't understand. How come I have to give myself these permissions? Isn't this what the udev rules are for? How come they don't do anything?

(Bonus question, if I unplug the USB receiver and plug it back in, all the user access stuff added by the udev rules disappear. They don't reappear even if I run "sudo udevadm trigger". I have to reboot my PC for them to reappear... Why?)

Here are the Steam udev rules in question:

➜ cat /lib/udev/rules.d/70-steam-input.rules
# Valve USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", 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"

# PowerA Wired Controller for Nintendo Switch
KERNEL=="hidraw*", ATTRS{idVendor}=="20d6", ATTRS{idProduct}=="a711", MODE="0660", TAG+="uaccess"

# PowerA Wireless Controller for Nintendo Switch we have to use
# ATTRS{name} since VID/PID are reported as zeros. We use /bin/sh
# instead of udevadm directly becuase we need to use '*' glob at the
# end of "hidraw" name since we don't know the index it'd have.
#
KERNEL=="input*", ATTRS{name}=="Lic Pro Controller", RUN{program}+="/bin/sh -c \"udevadm test-builtin uaccess /sys/%p/../../hidraw/hidraw*\""

# 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"

# ZeroPlus P4 (hitbox)
KERNEL=="hidraw*", ATTRS{idVendor}=="0c12", ATTRS{idProduct}=="0ef6", 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"

# HORIPAD for Nintendo Switch
KERNEL=="hidraw*", ATTRS{idVendor}=="0f0d", ATTRS{idProduct}=="00c1", 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"

# NVIDIA Shield Portable (2013 - NVIDIA_Controller_v01.01 - In-Home Streaming only)
KERNEL=="hidraw*", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7203", MODE="0660", TAG+="uaccess", ENV{ID_INPUT_JOYSTICK}="1", ENV{ID_INPUT_MOUSE}=""

# NVIDIA Shield Controller (2015 - NVIDIA_Controller_v01.03 over USB hidraw)
KERNEL=="hidraw*", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7210", MODE="0660", TAG+="uaccess", ENV{ID_INPUT_JOYSTICK}="1", ENV{ID_INPUT_MOUSE}=""

# NVIDIA Shield Controller (2017 - NVIDIA_Controller_v01.04 over bluetooth hidraw)
KERNEL=="hidraw*", KERNELS=="*0955:7214*", MODE="0660", TAG+="uaccess"

# Astro C40
KERNEL=="hidraw*", ATTRS{idVendor}=="9886", ATTRS{idProduct}=="0025", MODE="0660", TAG+="uaccess"

Last edited by Hubro (2020-09-02 18:06:12)

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,571

Re: [SOLVED] Why don't the udev rules in the multilib/steam package work?

Isn't this what the udev rules are for?

Can you actually post the actual udev rule so we can have a look at it.

Hubro

Member

Registered: 2019-03-09

Posts: 32

Re: [SOLVED] Why don't the udev rules in the multilib/steam package work?

Isn't this what the udev rules are for?

Can you actually post the actual udev rule so we can have a look at it.

Probably a good idea. Added them to the bottom of the original question.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,798

Re: [SOLVED] Why don't the udev rules in the multilib/steam package work?

How are you starting your session? A lot of dynamic permission handling is done between logind and udev if you don't have a proper systemd session that will break.

Hubro

Member

Registered: 2019-03-09

Posts: 32

Re: [SOLVED] Why don't the udev rules in the multilib/steam package work?

How are you starting your session? A lot of dynamic permission handling is done between logind and udev if you don't have a proper systemd session that will break.

Aha, that could explain a lot... I'm using xinit with i3. How would I go about starting a proper systemd/logind session? Do I have to use a display manager?

This is my .xinitrc file:

➜ cat .xinitrc 
#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

# Enable numlock
numlockx &

# Start HTTP proxy
proxyup

# Turn off monitor after 1 hours
xset dpms 3600 3600 3600
xset s off

# Composer
gtk-launch picom

# Wallpaper
source $HOME/.fehbg

# Gnome Polkit Agent
/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &

# Gnome Keyring
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
export SSH_AUTH_SOCK

bash "$HOME/Dropbox/Config/i3/build.sh"

exec i3

Hubro

Member

Registered: 2019-03-09

Posts: 32

Re: [SOLVED] Why don't the udev rules in the multilib/steam package work?

How are you starting your session? A lot of dynamic permission handling is done between logind and udev if you don't have a proper systemd session that will break.

Your question prompted me to read through the Arch xinit guide again, and it suggests forcing X to run on the same TTY that was used to log in: https://wiki.archlinux.org/index.php/Xinit#xserverrc

I followed that advice and now all the permissions seem to work flawlessly! I have rebooted and reconnected the USB receiver several times and it still works

Thanks!

Last edited by Hubro (2020-09-02 07:03:26)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,798

Re: [SOLVED] Why don't the udev rules in the multilib/steam package work?

Glad to hear, however I'm somewhat surprised as I did think that just doing the sourcing of the /etc/X11/xinit/xinitrc.d should be sufficient for most cases. But in any case this is likely the proper solution, so please mark as [SOLVED] by editing the title in your first post.