> The effort you need to go through to actually use these depends on how your distribution handles the file permissions of /dev/uinput. Some of them have it as

> The effort you need to go through to actually use these depends on how your distribution handles the file permissions of /dev/uinput. Some of them have it as root:input, in which case you just need to usermod -a -G input <yourusername> and then relog to get it working. Others have it as root:root so you either need to go do some reconfigurations to change its permissions or live with running the software using it as root. There's a trick to that. The TL;DR is "install the steam-devices package or similar" (https://github.com/ValveSoftware/steam-devices/ https://github.com/ValveSoftware/steam-devices/), which adds the following udev rule (and others, but this is the relevant one): # Steam Controller udev write access KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput" This does some udev magic to add an ACL to /dev/uinput allowing the currently logged in user to write to it. Its effect will be something like: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:cesarb:rw- group::--- mask::rw- other::--- The reason Steam has that udev rule is for something really cool called Steam Link, which allows you to use your Android phone, through your local network, as if it were a joystick for your computer. For some games (and its own user interface, which switches to a simplified "big picture" mode when you connect that emulated joystick) it does it directly without going through /dev/uinput, but for other games (which read the joystick input directly, without going through the Steam libraries) it sends the emulated input through /dev/uinput.