Steam Controller (2026) support

[mercifulboss]

With the new steam controller being released May 4th, will this program work with the new steam controller on linux?

---

(Martin): I'll edit in the TODOs here for visibility:

• Scrolling in the OSD with SC2 is way too fast
• Turning SC2 off from OSD menu works but SCC does not seem to register the controller being gone
• Touchpad input mapper isn't tilted like the touchpads themselves are, so it looks a bit off
• RSTICKPRESS has the wrong area defined (bigger ring instead of inner)
• There is no haptic feedback when pressing down on each trackpad, which is important to have on this specific controller, as there is no physical button - NOTE: how does Deck handle this?
• It would be nice to be able to disable Steam Controller support in the settings for use with Steam, and also have separate toggles for the V1 and V2
• RSTICK seems to be severely more limited than LSTICK when it comes to hitting corners (right upper corner on RSTICK is not hittable it seems - hard to test)

[C0rn3j]

Not unless someone PRs support for it

…

On Tue, Apr 28, 2026, 05:06 mercifulboss ***@***.***> wrote: *mercifulboss* created an issue (C0rn3j/sc-controller#98) <#98> With the new steam controller being released May 4th, will this program work with the new steam controller on linux? — Reply to this email directly, view it on GitHub <#98>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMQXEU2GM77JKOLKZXEF7D4YANZ7AVCNFSM6AAAAACYIXPO42VHI2DSMVQWIX3LMV43ASLTON2WKOZUGM2DAMRZHA3TCMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dnet890]

@mercifulboss the best workaround atm is Glossi or SISR. But, steam app need to be opened.

[Patola]

It works with the Steam Deck controllers already, even with a custom picture for it, so it should work with the Steam Controller 2.0 which is almost the same thing, no? Besides the new touch sensitivity of the laterals.

I have created a similar bug report for the original repository kozec#743

[Ryochan7]

For reference, there is C code out there showing how to interface with the new Steam Controller from SDL 3. That would come in handy for some custom bits not covered by current Steam Deck reader code.

https://github.com/libsdl-org/SDL/blob/main/src/joystick/hidapi/SDL_hidapi_steam_triton.c

[Ryochan7]

Ended up getting support working in my test mapper. I doubt I would get around to possibly adding support in this mapper. It is another resources at least.

So far, I am kind of disappointed with the new Steam Controller. GripSense was the deciding factor and, even with tweaking the settings, I do not really like it as a gyro activator. I cannot find a good range setting that can allow for quick deactivation while still allowing a loose grip. The IMU in the 2026 controller is definitely better than in the 2015 controller.

https://github.com/Ryochan7/DS4MapperTest/tree/master/DS4MapperTest/InputDevices/SteamControllerTritonLibrary

[pattontim]

I'm attacking this problem on three fronts. Android and Linux wired via libusb and Linux BLE via hidapi. I'm using one of kozec's C forks but it should be applicable.

The first thing is determining the endpoint we send feature reports to wired. D0G sends reports to interface 2 endpoint 3. Trying to claim this on the SC2 succeeds with libusb but throws kernel errors that the device on interface 2 is not claimed yet when you send try to send any feature reports. I tried interface 0 endpoint 1 but sending any data here gives me a pipe error.

We need to determine the interface and the disable lizard packet to send per platform

DS4Mapper and SDL suggest this command:

        public void DisableLizardMode()
        {
            byte SETTING_LIZARD_OFF = 0x00;
 
            byte[] featureData = new byte[FEATURE_REPORT_LEN];
            featureData[0] = 0x01;
            featureData[1] = 0x87; // ID_SET_SETTINGS_VALUES
            featureData[2] = 0x03;
            featureData[3] = 0x09; // SETTING_LIZARD_MODE
            featureData[4] = SETTING_LIZARD_OFF; // SETTING_LIZARD_OFF (2 bytes)
            featureData[5] = (byte)(SETTING_LIZARD_OFF >> 8);
            hidDevice.WriteFeatureReport(featureData);
        }

The SC2SmoothBrainifier suggests a simpler command,

            byte[] featureReport = new byte[65];
 
            // 1. Valve Feature Report ID
            featureReport[0] = 0x01;
 
            // 2. ID_CLEAR_DIGITAL_MAPPINGS (The modern Valve Lizard-Mode Kill-Switch!)
            featureReport[1] = 0x81;
 
            // 3. Payload Length is 0 because this command takes no additional arguments
            featureReport[2] = 0x00;

The SDL code for android doesn't even disable lizard mode so dunno where to start there.

[Patola]

So, I've got to the point where I got a fully functional sc-controller window with all bindings apparently working.

(this is not a mockup)

Code is at https://github.com/Patola/sc-controller-cc/tree/steam-controller-v2 (I just pushed my changes), will in time commit to master.

However, there are still many, many areas to work, i.e. I also need to backport some of my additions (like adding inputs for thumbnail touch) to the steam controller v1 and steam deck, and revamp the steam deck interface, and check the other controllers compatibility. I have still bugs regarding the OSD and the Input Test Mode, etc...

And still many things for the future, like HD Rumble (seems complicated), bluetooth connectivity support (might be simple) and other things.

Problem is... It's "vibecoded" (I have taken all the decisions and did almost all the drawings) but I wrote no code, Claude Code did. I don't know if you guys will accept this kind of Pull Request, notwithstanding that it's already big and it's growing. I am very clear on what I am using, even to the point of naming my fork "sc-controller-cc", "cc" for "Claude Code".

Let me know your thoughts, and don't curse my parents, please.

[Patola]

BTW, Claude Code very elegantly mapped the Steam Controller v2 protocol here: https://github.com/Patola/sc-controller-cc/blob/steam-controller-v2/docs/steam-controller-v2-protocol.md

[C0rn3j]

Glanced over it quickly:

Do we really need entirely new scripts for SC2 SVG image generation when we already have generate_icons.py and generate_svg.py?

It looks like the mini icons of sc2 are just the sc1 icons?
EDIT: I see you noted that down as a TODO

SC2 released in 2026, not 2025.

I am not sure about renaming Stick Press to Left Stick Press - unsure if other controllers that SCC supports don't have the default stick placed on the right for example... I believe I have an open issue to check this out.

In fact in your code I see references to 2x RSTICKPRESS and 1x L and 1x without L? Why is that?

    (SC2Button.LSTICKPRESS, SCButtons.STICKPRESS),
    (SC2Button.RSTICKPRESS, SCButtons.RSTICKPRESS),

Since most of the vibed code is in new files as a new driver and tools, I think it's not a huge issue, just gotta pay attention to the existing parts that are being edited.

[Ryochan7]

Need to test this out sometime. I don't really have a problem with vibe coding so long as it is reviewed and tested before integrating into a project.

From what I see in the code, the data parsing portion is out of date. I cannot remember when but Valve pushed out a firmware update for the Steam Controller 2026 in the last couple of weeks that changed the input report ID. The controller uses report ID 0x45 (old BLE id) for wired and puck connections now as well. That change broke Steam Controller compatibility with earlier releases of SDL 3. It is probably best to check against both report ID values when reading from the Steam Controller; that is what modern SDL 3 does as well.

[Patola]

I'll address every observation here to get that fixed, give me a few days. My local code has already improved some stuff (like the OSD), this is a work in progress after all. I will fix the reference on SC2 to 2026, will address that residual naming and the data parsing out of date.

[Patola]

Glanced over it quickly:

Do we really need entirely new scripts for SC2 SVG image generation when we already have generate_icons.py and generate_svg.py?

This is done so that adding new controllers becomes easier. There is another generator script for the configuration display image done via OSD. I have made a new image, restylized by hand in inkscape, of the steam controller v2 for this screen, just like the steam controller v1 has.

It looks like the mini icons of sc2 are just the sc1 icons? EDIT: I see you noted that down as a TODO

Actually the glyphs that steam controller 2 uses are generic assets -- deck.config.json → LB, RB, LT, RT, STICK, TOUCHPAD, RGRIP, LGRIP -- they don't point at v1 artwork, exactly like the code for the Steam Deck does. Should I change this and completely separate these assets?

SC2 released in 2026, not 2025.

Fixed in the README.

I am not sure about renaming Stick Press to Left Stick Press - unsure if other controllers that SCC supports don't have the default stick placed on the right for example... I believe I have an open issue to check this out.

In fact in your code I see references to 2x RSTICKPRESS and 1x L and 1x without L? Why is that?

(SC2Button.LSTICKPRESS, SCButtons.STICKPRESS),
(SC2Button.RSTICKPRESS, SCButtons.RSTICKPRESS),

The answer from Claude:

I checked the SC2Button enum thoroughly (sc2.py:87-126). It has exactly two stick-press constants — LSTICKPRESS (1<<15, L3) and RSTICKPRESS (1<<5, R3). There is no SC2Button.STICKPRESS. So the enum is already what the dev wants.

The "third constant" is a misread: the STICKPRESS on line 143 is SCButtons.STICKPRESS — a member of the generic, cross-driver button enum in constants.py:99, not of SC2Button. The mapping translates the v2 hardware bits into that generic set:

SC2Button.LSTICKPRESS → SCButtons.STICKPRESS
SC2Button.RSTICKPRESS → SCButtons.RSTICKPRESS
The asymmetry (left→STICKPRESS, right→RSTICKPRESS) is exactly the v1 legacy the dev suspected — but it lives in the generic enum, which names the left stick-press STICKPRESS (v1 had a single, left stick; confirmed by modeshift_editor.py: STICKPRESS = "Left Stick Pressed", RSTICKPRESS = "Right Stick Pressed"). And line 144 isn't "RSTICKPRESS twice" by mistake — the hardware enum and the generic enum simply both happen to name the right stick-press RSTICKPRESS.

Crucially, the Steam Deck driver does the identical thing (steamdeck.py:218-219): DeckButton.LSTICKPRESS → SCButtons.STICKPRESS, DeckButton.RSTICKPRESS → SCButtons.RSTICKPRESS. So sc2 is consistent, not buggy. Renaming SCButtons.STICKPRESS → LSTICKPRESS would be an upstream-wide breaking change (the "STICKPRESS" key is baked into the saved-profile format and the daemon's Event: protocol, and used by every driver + the GUI). Not something to do in this fork.

So no functional change — but the confusion is real, so I'll add a comment documenting it

Since most of the vibed code is in new files as a new driver and tools, I think it's not a huge issue, just gotta pay attention to the existing parts that are being edited.

Unfortunately as I am trying to polish as much as I can and treat every little corner and every sharp edge of sc-controller to compensate for doing this with AI code assistance, I am forced to also deal with the core code. It is kind of irreducible that I will not know fine details of the code: although I do some programming on my job and for fun, I do not know much of widgets and X11 libraries and hacks and the likes, so when reading the code I wouldn't immediately find any issues or problems with the logic. But I am being as diligent as I can, testing every new change and repeatedly test if everything is in order. I am also trying to respect every design decision and go along with it.

The last version of sc-controller without my changes was already broken in a number of places for me (on the first steam controller), specially because I migrated to Wayland. Some things won't work in Wayland, like the "Autoswitch Options >>" on the OSD, because wayland does not allow the code to inspect and hook on other windows like Xorg. I don't know if there is a portal workardound around that, but as I could not get it to work, now the OSD Menu, when it is on wayland and the user selects that option, just says "Autoswitch needs an X11 session".

The "Edit Bindings" entry also uses a series of hacks that is not translatable to wayland (I can paste the technical explanation if you want) and is not working properly for me even in X11 (yes, I have made every test both on KDE Wayland and KDE Xorg, and I've tested some stuff under icewm and Gnome too). Specifically, the fact that is spawns a new sc-controller process with the --osd flag leads to all kinds of issues and race conditions, often making the daemon or interface crash or spawn multiple identical sc-controller windows. But it sounds to me a bit redundant, since you can edit the OSD bindings clicking on "Advanced" on Settings → Menus & Keyboard, so instead I have changed it to just call that window, that is not navigable with joystick on an overlay but works for that function. I ended up removing the entire OSD Edit Bindings menu code, but it was via a single commit from version tag v0.4 to v0.5, so it is easily recoverable from git if needed (that removal will also make it easier/feasible to port to GTK4, btw).

My thought about this is that editing the OSD bindings is something you would do very few times, and never recurrently, so it should not be on the OSD menu on the first time, it's using precious real estate that it doesn't need. The entry is still there calling the conventional window to change the OSD bindings, but I would like your permission to remove it from there.

Another change I have done was in the "All Profiles" submenu because I have 300+ profiles and the list would leak from the screen, so now it autoresizes and scrolls smoothly if it's bigger than the screen.

I am still working on it, going through everything, and now trying to fix the Input Test Mode that is not fully functional.

I want to touch other parts too. Bring my thumbstick touch change to the steam controller v1 and steam deck. Fix the Steam Deck part too, that has some shortcomings. I want to thoroughly test for multiple joysticks, which lead me to the questions:

• How is sc-controller supposed to work with multiple joysticks? Be it identical ones (e.g. two steam controllers v1) or different ones (e.g. One steam controller v2 and a dual shock 4).
• Does it show just one window for one controller?
• Does it open multiple windows, one for each controller?
• If it is multiple window, when one of the controllers is disconnected or turned off, does the window close?
• If it is a single window, which means it only treats one joystick at a time, how is its priority list?
• How does the "Use Serial Numbers to Identify Controllers" setting changes this? I had this setting on in the past but it did not work well, so I ended up unsetting it.
• Since the Autoswitcher is not working on Wayland, how to deal with that? I am leaving that code there because of course X11 users might want to use this

So far the GUi and driver are looking good, many bugs fixed, I pasted the screenshot from v0.2, I'm on v0.5 of my changes, https://github.com/Patola/sc-controller-cc/tree/steam-controller-v2 -- I am sure to do a lot more this weekend.

[C0rn3j]

Does it show just one window for one controller?

Does it open multiple windows, one for each controller?

2x SC1 https://github.com/user-attachments/assets/609a3505-a369-4208-882f-118a408cac79

If it is a single window, which means it only treats one joystick at a time, how is its priority list?

Well, it handles both at the same time.

With the default xbox bindings, which make it move the mouse cursor, if one moves one joystick to the left, and second down, it will combine and make the cursor go diagonally. If you move both in one direction, it seems the speed adds up too.

[Patola]

Thanks, at this point I've seen that menu. And I've done all kinds of tests with it. For some reason it is not working with my Dual Shock 4 (bluetooth). But it's working with 4 steam controller 1's and 1 steam controller 2, even though using that many controllers is not viable -- they disconnect the whole time, they lose pairing (go figure) and sometimes my USB bus drops everything and needs a reboot to connect. When I took this photo the rightmost one had just disconnected randomly:

1 steam controller 2 + 2 steam controller 1's are stable though. I've changed the interface so that the pull-down above only appears if there is more than one controller, and allows you to select the controller. The pull-down with profiles alway appear. This way the interface is not unwieldy with 5 pull-down menus if you have 5 controllers like the ones I tested. :)

I'm still very active on fixing bugs -- trying to get the steam deck to work well, will have to create a couple new parts for the drawing. You can follow my daily patches here.

I've also submitted the current code to serious abuse to find race conditions, lock issues and the likes. So far fixed a few and it's becoming every day more solid.

[C0rn3j]

Your PS4 controller not working is likely due to UHID being enabled by default on your system. It's not bad, we just don't support it yet.

There's a PR that adds HIDRAW for PS4 controllers so that may or may not work around it, but UHID still needs to be implemented after that.

#22