Bug 18627 - Finding the proper udev rule for the Steam Controller
Summary: Finding the proper udev rule for the Steam Controller
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Rémi Verschelde
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-05 13:45 CEST by Rémi Verschelde
Modified: 2016-06-06 09:02 CEST (History)
1 user (show)

See Also:
Source RPM: steam-udevrules-1.0.0.52-1.mga6
CVE:
Status comment:


Attachments

Description Rémi Verschelde 2016-06-05 13:45:05 CEST
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/
Rémi Verschelde 2016-06-05 13:46:51 CEST

CC: (none) => mageia

Comment 1 Rémi Verschelde 2016-06-05 14:32:39 CEST
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
Resolution: (none) => FIXED

Comment 2 Colin Guthrie 2016-06-06 08:46:27 CEST
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
Comment 3 Rémi Verschelde 2016-06-06 09:02:14 CEST
Should I move the rule to 72 to be safe?

Note You need to log in before you can comment on or make changes to this bug.