| Summary: | Finding the proper udev rule for the Steam Controller | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Rémi Verschelde <rverschelde> |
| Component: | RPM Packages | Assignee: | Rémi Verschelde <rverschelde> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | steam-udevrules-1.0.0.52-1.mga6 | CVE: | |
| Status comment: | |||
|
Rémi Verschelde
2016-06-05 13:46:51 CEST
CC:
(none) =>
mageia Alright, with the feedback of an Arch user, I finally managed to adapt the rules so that they work. There might have been a conflicting uaccess rule, as increasing the load order made it work.
---------
$ cat SOURCES/80-steam-controller-perms.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"
---------
I would still welcome feedback on this new rule, if it could be further improved. I don't know for example if the added `TAG+="uaccess"` for the first line is useful, or if only the increased load order was enough to fix my issue. But I'm a bit tired of trial and error so I'm not too keen on investigating further just yet :p
New rules pushed as steam-udevrules-1.0.0.52-2.mga6.Status:
NEW =>
RESOLVED Interesting that 80 priority works as uaccess stuff is processed at 73 (see the trigger of the uaccess builtin in 73-seat-late.rules). I'd have thought any external uaccess stuff should need to be 72 or lower... weird Should I move the rule to 72 to be safe? |
TL;DR: Need help to write a proper udev rule for uinput write access. Opening an issue against my own package because I need some help to get things right. The Steam Controller is a game controller developed by Valve. It has some innovative features to be used in Steam games, but can also in theory be used as a regular controller (Ã la Xbox 360) via an emulation layer. Steam can do this emulation, as well as the libre `steamcontroller` package (via `sc-xbox.py`). For this, the device apparently needs write access to /dev/uinput. Valve provides the following udev rules in its package (that I put in steam-udevrules, so that it can be used without Steam and with the libre `steamcontroller`): --------- $ cat /usr/lib/udev/rules.d/99-steam-controller-perms.rules # Valve USB devices SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666" # Steam Controller udev write access KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess" --------- This is apparently not sufficient as Steam gives such error messages: Controller 0 Gamepad uses xinput : true Couldn't initialize virtual gamepad: Couldn't open /dev/uinput for writing I've tried many solutions to fix this udev rules, such as adding `MODE="0660" GROUP="games"` as suggested by some [0], or `TAG+="udev-acl"` as suggested by others [1], or `OPTIONS+="static_node=uinput"` as Valve seemed to have advised initially [2]. I _used_ to have this working with some voodoo rules, but I can't seem to find it again, and would thus appreciate some feedback from a systemd/udev expert (Colin? :)). [0] https://wiki.archlinux.org/index.php/Gamepad#Steam_Controller_Not_Pairing [1] https://wiki.gentoo.org/wiki/Steam_Controller [2] http://steamcommunity.com/app/353370/discussions/0/490123197956024380/