Steam Controller (2026) Support

[isXander]

This controller is releasing soon, 4th May, so I thought it best to start a discussion, as well as a tracking issue for this controller.

The Steam Controller (2026) features the following non-standard inputs;

• 2 touchpads
  • each touchpad has haptic feedback, and is pressure sensitive
• middle Xbox-like menu button
• 4 back buttons
• HD haptics
• a new "Grip Sense"
  • Grip Sense is a feature that detects whether you are gripping the handle parts of the controller.
  • It is unclear whether this will be exposed as two separate inputs (left and right) or as one
• Gyro
• Touch sensor in thumb sticks

The controller has three input methods:

1. Wired
2. 2.4 GHz
3. Bluetooth

The controller has an internal battery which means it will also expose battery level.

Demonstrations of the 2.4 GHz dongle have shown a live -dB signal readout.

My concern with this controller is how the Steam Client will interact with it, with the Steam Deck, the Steam Client takes exclusive control over the HID, making SDL unable to use its advanced features. I wonder whether it will be the same with the Steam Controller?

[Kuratius]

This might be a bug but I believe the steam client doesn't actually take exclusive access. In my testing an SDL application that is not launched as non-steam game can read and process input in parallel with the steam client. I think SDL and the kernel driver are merely configured to deactivate themselves if they think steam input is using the device.
I can only speak based on my testing with the original steam controller though.

You might have to patch SDL for some features of the new controller, but I believe the skeleton for reading the raw packets it sends already exists in SDL.

[isXander]

This might be a bug but I believe the steam client doesn't actually take exclusive access.

See #9148 and it's related issues

[Kuratius]

I'm aware of that issue, but as far as I can tell reading the input in parallel with steam works fine, it only becomes a problem if the application is launched through steam.
The virtual gamepad issue doesn't happen.
Might be because I'm setting some hints for SDL to use the HID API. The problem is more so that there is no good way to tell steam to not also process the input in parallel.

I'm not entirely certain if two applications reading the same input device won't have unwanted side effects like dropped movement packets though.

[isXander]

I'm aware of that issue, but as far as I can tell reading the input in parallel with steam works fine, it only becomes a problem if the application is launched through steam. The virtual gamepad issue doesn't happen. Might be because I'm setting some hints for SDL to use the HID API. The problem is more so that there is no good way to tell steam to not also process the input in parallel.

From the thread I linked:

Please also note that there is a quirk in the SteamDeck kernel driver that hides the classic gamepad device as soon as the hidraw device is opened (see torvalds/linux@master/drivers/hid/hid-steam.c).
As an overall result, only the Steam virtual gamepad may be present and accessible.

Regardless, this thread should be tracking Steam Controller, not Steam Deck issues, they can go in the other threads.

[Kuratius]

I think you don't understand what I'm saying. I'm talking about the steam controller, not the deck. And I have a working application that reads the controller's touchpads via SDL while steam is running so what you're quoting about the kernel driver's behavior is completely irrelevant, as I'm not using the kernel driver or the virtual gamepad provided by steam.

[isXander]

Sorry for the confusion!

I'm under the assumption that the new Steam Controller will have extremely similar firmware and client integration and quirks as the built in device on the Deck, and will not share much heritage software-wise with the original.

I'd be happen to be proven wrong when they release it soon though!

[Kuratius]

I think in principle it should be possible to get similar behavior on the new one, the question is just whether that's ideal.
I'm like 60-70 % sure what I'm doing isn't the "intended" way as you're not supposed to have 2 different drivers active for the same peripheral. It'd be good to have some standardized interface to tell a driver (even if that driver is the steam client) to back off if an application needs exclusive access.
People apparently use a tool called hidhide for this purpose on windows, though I'm unsure what the linux equivalent would be.
Maybe permission locking the files corresponding to an input device to a different user?

This seems to be similar: https://old.reddit.com/r/linux_gaming/comments/1drc2hv/anything_like_hidhide_on_linux/law8sjb/

Edit:
I think the idea above might not work because I'm not sure it would affect an already open file descriptor.
If Steam honors it flock() or https://docs.kernel.org/driver-api/input.html EVIOCGRAB might work.
Or alternatively HIDIOCREVOKE
https://github.com/torvalds/linux/blob/e75a43c7cec459a07d91ed17de4de13ede2b7758/include/uapi/linux/hidraw.h#L49
https://lkml.org/lkml/2024/8/27/2

There must be some path towards supporting this, even if that solution is faking device hotplugging to then temporarily take control of it (because steam already has to be able to handle a user plugging or unplugging the controller or its wireless adapter anyway).

[isXander]

I've not yet got my hands on one, but one of my users has:

On Windows:

• Without the Steam Client running, the controller is not detected at all.
• With the client running, the controller is detected as "Steam Controller" (not "Steam Virtual Gamepad"!) but features such as Gyro do not work.

[VladFlorinIlie]

Hello everyone! I have a Steam Controller 2026 and I tried to test the touchpads and the rumble using the latest SDL3-SYS Rust library (0.6.3). I have created this gist with the test: https://gist.github.com/VladFlorinIlie/131fade4955b1ac60fb89e52f157b3fa

The output of the test is the following:

Waiting 2 seconds for controllers to enumerate...
Successfully opened gamepad: Some("Steam Controller")
SDL3 reports 0 touchpads for this device.
Attempting to trigger rumble (32000, 32000) for 1000ms...
set_rumble returned ERROR: SDL error:
Keeping program alive for 3 seconds to feel the haptics...
Done.

So indeed, SDL3 library cannot detect the touchpads of the new Steam Controller 2026 and also the rumble seems to fail almost immediately (in the test above, the rumble should have been triggers for a second, instead it worked for a few millis).

[BlueInterlude]

I am unable to get the gyro working for non-Steam games (primarily emulators) on the Steam Deck in Game Mode, using the Dolphin emulator specifically. A comment on the linked PR seems to suggest gyro's working prior to that PR being merged, #15528 (comment)

However, it looks like Steam doesn't let you disable Steam Input for the Steam Controller in Game Mode which is usually how I've enabled gyro for controllers in the past.

As a workaround, I've set the Gyro to D-Pad (following the tip here, ValveSoftware/steam-for-linux#9359 (comment)) which also doesn't seem to work either.

This might not be SDL related though since Game Mode seems to be lacking a feature for the Steam Controller specifically?

[ceski-1]

Some test notes:

Windows 11:

1. Steam running and testcontroller added as a non-Steam game:
   • Steam Controller is forced to "Enabled, always required" for Steam Input
   • When testcontroller is launched, the Steam Controller appears (correct name) but with no direct access to any features beyond the typical default Xbox-style layout, so it appears that SDL3 is being ignored
2. Steam running in the background, and testcontroller launched directly, outside of Steam:
   • All extra functionality is present and working correctly
   • However, because Steam is still in the background and unaware that an SDL3 app is running outside of it, Steam Input is still applying the "Desktop Layout", resulting in double inputs
3. Steam not running, and testcontroller launched directly, outside of Steam:
   • All extra functionality is present and working correctly

The above issues are also present on a Steam Deck (SteamOS beta channel) in Desktop Mode. In Game Mode, the first issue is present too, while the others don't really apply. Both the Steam Controller and the Steam Deck's built-in controller have the same issues.