Native Steam Controller 2 support: what already works and what is missing (research)

Start with the SDL gamepad type switch in runtime/src/gfx/platform.cpp:111-126 and the PadKind definition in runtime/include/nxrt/input.h:70; the issue says the controller has not been tested with physical hardware. The proposed first step is to detect the Steam type, map it to Xbox prompts, log the SDL type name in pkp.log, and test with the controller. The broader options also involve prompt parsing and overwrite code, launcher pages, and [padmap], so the scope and expected behavior need decisions.

Read-only research on the second-generation Steam Controller (Valve's "Triton" in SDL). Nothing was run with the physical device; every behaviour below is read from source or public pages.

Summary

• The device is real and shipped: the second-generation Steam Controller launched 2026-05-04 at $99. SDL calls it "Triton" and has had a driver since 2025-11-12.
• Recompia already links SDL 3.4.18, which came after that driver, so the pad should already be read as a normal SDL gamepad, with gyro, accel and rumble.
• What is missing is only the presentation: the runtime shows Xbox, PlayStation, Switch or keyboard prompts. A Steam Controller falls into PadKind::Other, so auto prompts would not pick a matching glyph set.
• CC0 glyph art exists: Kenney Input Prompts 1.5 added Steam Controller art, and the project already ships a pack built from Kenney 1.5a.

Our code

• Pad kind is decided by a switch over SDL_GetGamepadType (runtime/src/gfx/platform.cpp:111-126). There is no SDL_GAMEPAD_TYPE_STEAM case, and PadKind has only four values (runtime/include/nxrt/input.h:70).
• [prompts] style accepts switch, xbox, playstation, keyboard, auto. A new glyph set needs a new value, a parser alias and a launcher entry.
• The prompt overwrite only knows Xbox, PlayStation and keyboard art (runtime/games/pkp/pkp_kbm.cpp:578).
• Gyro and accel already flow (runtime/src/gfx/platform.cpp:167-168); rumble goes through the two SDL motors. Paddles, trackpad clicks and touch are unused.
• [padmap] has no paddle, QAM or trackpad source entries.

What a new device needs, place by place:

1. Type detection: add SDL_GAMEPAD_TYPE_STEAM (and check the Triton type) in platform.cpp:111, and add PadKind::Steam (or map it to Xbox).
2. Glyph set: a steam/ folder in prompt_icons.pak, a PromptStyle::Steam, a parser alias, and a case in pkp_kbm.cpp:578.
3. Labels: Steam face buttons are lettered A/B/X/Y like Xbox, so label_abxy keeps working.
4. Gyro/touch: gyro already flows; trackpads are not read. The game has no pointer input, so trackpads would be for menus/camera only.
5. Rumble: already used.
6. F1 and launcher pages: add the entry to the Button prompts list.

Icons and licenses

• Kenney Input Prompts 1.5 added "Steam Controller, Frame, Valve Index & Meta Quest"; the pack is CC0. The project already ships a Kenney 1.5a pack and keeps the CC0 licence text; CC0 is GPL-3.0-compatible.
• Valve's glyph API returns art loaded at run time from the player's Steam folder; that is not a licence to copy it into the repo. Rule: do not copy Valve art; use Kenney CC0 art only.
• Using the Steam Input API needs the Steamworks SDK and an app id, which a Non-Steam shortcut does not have.

Options

• A. Steam Input as an Xbox pad plus a shipped layout. Small effort, low risk. Players get a working pad with Xbox glyphs. Needs a layout document and a device test.
• B. SDL gamepad type plus our own glyph and gyro code (recommended). Small–medium effort, low risk: detect the type, add a Steam glyph set from Kenney CC0 art, show it under auto, add paddle and trackpad-click entries to [padmap]. Under Proton with Steam Input on, the game sees an Xbox pad, so the Steam glyphs would not show there unless a setting is added.
• C. Steam Input API through Steamworks. Large effort; needs an app id, the SDK and a licence check.
• D. Raw HID. Large effort, high risk, duplicates SDL. Not advised.

First small step: add a pad-kind case for the Steam type, map it to Xbox prompts, log the SDL type name in pkp.log, and test with the real pad.

Not verified

• Nothing was run with the physical controller.
• Whether SDL reports SDL_GAMEPAD_TYPE_STEAM for it, and the USB IDs.
• Which SDL release first contained the Triton driver, and whether 3.4.18 has all of today's fixes.
• Whether Kenney's Steam Controller art is the new controller and covers paddles and trackpads.
• Whether Steam picks up a layout file written by the launcher for a Non-Steam shortcut.
• The Steamworks SDK licence terms for redistribution in a GPL-3.0 project.

Open questions

1. Can a physical controller be used to check the first step?
2. Which platforms come first: Windows native, Linux/Proton, or the Steam Deck?
3. Should the game show Steam glyphs when Steam Input hands it an Xbox pad, or only when the real Steam pad is seen?
4. Should gyro aiming be on by default in the shipped layout?