FS#47330 - [steam] Steam Controller rules not working anymore
Attached to Project:
Community Packages
Opened by TesX (tesfabpel) - Friday, 11 December 2015, 08:22 GMT
Last edited by Levente Polyak (anthraxx) - Monday, 05 December 2016, 22:53 GMT
Opened by TesX (tesfabpel) - Friday, 11 December 2015, 08:22 GMT
Last edited by Levente Polyak (anthraxx) - Monday, 05 December 2016, 22:53 GMT
|
Details
The steam package (version 1.0.0.51-1) provides the
steamcontroller's udev rules on its own.
Anyway (at least for me), they don't work anymore... The controller gets connected to the receiver but Steam can't detect it (even pairing, doesn't work anymore). I tried installing python-steamcontroller-git from AUR and then launching sc-gyro-plot.py but it didn't work... Then I tried running it with sudo and it was running fine... |
This task depends upon
Closed by Levente Polyak (anthraxx)
Monday, 05 December 2016, 22:53 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#46752
Monday, 05 December 2016, 22:53 GMT
Reason for closing: Duplicate
Additional comments about closing:
Using the rules provided as a previous workaround:
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
KERNEL=="uinput", MODE="0660", GROUP="myusername", OPTIONS+="static_node=uinput"
works fine.
[1] https://wiki.archlinux.org/index.php/Talk:Gamepad#Steam_controller_udev_rules
Does it work after you run the following?
# setfacl -m mask::rwx /dev/uinput
># setfacl -m mask::rwx /dev/uinput
Nope, no difference. Controller not recognised (even by steam).
People seem to be having varying trouble with this. For some the rules supplied with the steam package work fine. Some get keyboard emulation but not controller emulation. Some (including me) get nothing at all.
if using package udev rules (tag+=uinput only no group) then /dev/input/js0 and /dev/input/event21 are NOT created.
The only visible permissions difference I could see with getfacl was that group is --- with the steam rules whereas my custom workaround rules gave rw to users group.
< SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666", TAG+="uaccess"
---
> SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"
Looks like a regression from https://bugs.archlinux.org/task/46752
FS#46825.From what I can tell the rule provided in the [steam] 1.0.0.51-1 package does work but is too late in the priority.
When using the rule provided in /usr/lib/udev/rules.d/80-steam-controller-permission.rules the first connection of the controller will work. However after turning off the controller and turning it back on it will partially work.
The /dev/input/js0 and corresponding /dev/input/event* won't be created so controller emulation in game will fail to function.
After renaming that rule file from 80-steam-controller-permission.rules to 70-steam-controller-permission.rules it seems to work fully for me. Even after turning off the controller and turning it back on multiple times it will continue to work properly for me having raised the priority of the rule. The /dev/input/js0 and corresponding /dev/input/event* gets created.
Having fiddled around some more with the file name of the rule I've found that it continues to work at a 72-steam-controller-permission.rules and fails at a 73-steam-controller.rules. I don't understand enough about udev rules to know why this is the case. Yet it seems to be a rule loading priority issue.
It has this line:
TAG=="uaccess", ENV{MAJOR}!="", RUN{builtin}+="uaccess"
According to this:
http://man7.org/linux/man-pages/man7/udev.7.html
it says that
RUN{type}
Add a program to the list of programs to be executed after
processing all the rules for a specific event, depending on
"type":
"program"
...
"builtin"
As program, but use one of the built-in programs rather than
an external one.
Then, I searched RUN{builtin}+="uaccess" and the first result was:
https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-uaccess.c
So, maybe, after 73-seat-late, all the uaccess tags don't work anymore...
This file is owned by systemd and in the C source file I linked before it explicitly check if logind is running (line 43) otherwise it returns...
@Max do you have systemd and logind installed and enabled?
If not, maybe that's the reason the rule works correctly with a priority of 80.
PS: Sorry for my english...
FS#49926,FS#47330andFS#46752are all the same.Right now the controller is working perfectly fine when it was plugged in before booting. As
FS#47995explains, this is because the uaccess tag is applied by udev rules after it is consumed by the logind udev rule. Since the tag would usually be applied before the rule before logind starts, the controller works fine after boot, but not, for hotpluggin or suspend/resume cycles.The correct solution would indeed be moving the steam controller udev rule priority to 70 and not as the other bugs suggest to change the mode or use a special steam controllers group for this. This ensure that the uaccess tag mechanic is in use (acl based access rights to the user whose session is active according to logind).
[1] http://packages.ubuntu.com/xenial/steam
[2] https://packages.debian.org/sid/steam-devices
I seem to get an effective permission of --- on /dev/uinput due to being masked to ---, for a reason I didn't figure out yet.