Steam Controller Support
Steam Controller
As of version 2.6.0, the library supports the steam controller natively, meaning you can access all its controls. While this controller does require a specific USB dongle, unlike most dongle-based controllers it is able to report disconnections - the device nodes only appear if the controller is turned on.
- class approxeng.input.steamcontroller.SteamController(dead_zone=0.1, hot_zone=0.05, **kwargs)[source]
Wireless steam controller. As of Jan 2021 this works with modern linux installations without any messing around, and supports a lot of extra controls as a result!
The unusual controls are as follows, firstly buttons. Note that both the trackpads have touch buttons as well as the click (on the right trackpad) and the d-pad ‘buttons’ on the left one. The controller doesn’t have a true d-pad, but you can use the left trackpad in place of one (although it’s heavy to activate)
Standard name
Steam Controller
square
X
triangle
Y
circle
B
cross
A
ls
Left stick click
rs
Right trackpad click
rtouch
Right trackpad touch
select
Left arrow
start
Right arrow
home
Steam button
dleft
DPad left click
dup
DPad up click
dright
DPad right click
ddown
DPad down click
dtouch
DPad (left trackpad) touch
l1
Top left trigger
l2
Middle left trigger
l3
Base left trigger
r1
Top right trigger
r2
Middle right trigger
r3
Base right trigger
The controller has three xy axes with corresponding circular axes as well as analogue triggers on the middle trigger buttons:
Standard name
Steam Controller
lx
Stick horizontal
ly
Stick vertical
rx
Right trackpad horizontal
ry
Right trackpad vertical
dx
Left trackpad horizontal
dy
Left trackpad vertical
lt
Middle left trigger
rt
Middle right trigger
- __init__(dead_zone=0.1, hot_zone=0.05, **kwargs)[source]
Populate the controller name, button set and axis set.
- Parameters:
controls – A list of
Button,CentredAxis,TriggerAxisandBinaryAxisinstancesnode_mappings – A dict from device name to a prefix which will be applied to all events from nodes with a matching name before dispatching the corresponding events. This is used to handle controller types which create multiple nodes in /dev/input by keying on the device names reported to evdev for each node. Nodes are grouped by physical or unique ID first so should, in an ideal world at least, all correspond to the same physical controller. This is necessary to support some controllers on modern kernels, particularly 4.15. If not specified, or none, then no per-node renaming is applied. Device names which do not appear in this map are not assigned a prefix, so it’s legitimate to only assign prefixes for ‘new’ functionality which has magically appeared in a later kernel. Similarly, this is ignored if there is only one device node bound to the controller instance, so the best practice is to leave the older mappings named simply by their code, and only use this to handle secondary device nodes such as motion sensors.
dead_zone – If specified, this is applied to all axes
hot_zone – If specified, this is applied to all axes
ff_device – If specified, this is a force feedback compatible device node, defaults to None