Steam Controller Support

../_images/steam-controller.jpg

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, TriggerAxis and BinaryAxis instances

  • node_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