MagicBeanDev/Hookshot

Archived

Watch

Fork 0

fix(input): read a steam controller's gyro when steam starts the game #2495

Merged

dylmart merged 3 commits from fix/steam-controller-gyro into main

2026-11-11 22:47:26 +00:00

dylmart commented

2026-11-11 20:59:24 +00:00

(Migrated from github.com)

Fixes #1897.

Started from Steam, SDL gets Steam's controller ignore list (SDL_GAMECONTROLLER_IGNORE_DEVICES), which has Valve's own pads in it, along with SDL_GAMECONTROLLER_ALLOW_STEAM_VIRTUAL_GAMEPAD=1. So SDL only opens Steam Input's stand-in pad. That pad has no gyroscope, so motion controls found nothing.

host/steam_pads.h (new, no SDL in it): takes Valve's 0x28de entries out of the list, except the Steam Deck's built-in controls (0x28de/0x1205), and keeps the rest in order. The Deck's stay because SDL's Steam Deck driver resets their trackpad and button settings as it opens them, and that isn't tested beside Steam Input in Game Mode yet. A list from a file (@path) or one too long for the buffer is left as it is. Also the rule for when a pad gives its motion only.
host/hos_sdl.c / .h: three optional calls, SDL_Get(Gamepad|GameController)Vendor, SDL_Get(Gamepad|GameController)SteamHandle and SDL_SetHintWithPriority (SDL 2.30+ and SDL3 3.2+). The list is set with override priority, since Steam's environment variable beats a plain SDL_SetHint. An SDL without all three leaves the list as Steam set it, so a real pad and its stand-in never both play.
host/pad_sdl.c: while a stand-in pad (one with a Steam handle) is open, the real Valve pad gives its motion only. Its buttons and sticks come through the stand-in as the player's Steam layout maps them, so they aren't counted twice, and its rumble goes through Steam too. Its presses still mark it the pad used last, so motion_poll reads its gyro. It isn't counted in the controller total or used for the prompts name. When no stand-in is open, the real pad plays as before. A real Valve pad that SDL opens with no motion sensors (an SDL with no driver for it) is logged once, so the next person with #1897 sees why.
tests/test_steam_pads.py: the list filter (the Deck's entry kept) and the motion-only rule.

SDL requirement: gyro only comes through if the SDL the game loads has a driver that reads the pad's motion sensors. CachyOS's sdl3 3.4.18 and 3.4.20 and Steam's bundled SDL3 do for the 2026 puck. One without it gets this line and no gyro, and buttons work as before:

hid: "Steam Controller": no motion sensors through this SDL, so Motion controls can't read it; its buttons come through Steam Input's pad

Testing

Linux (CachyOS, Hyprland), 2026 Steam Controller (wireless puck). Not tested with the original Steam Controller.

Started from Steam: gyro works and each input registers once. The log:

hid: Valve's controllers taken out of Steam's ignore list, for their motion sensors
hid: controller "Steam Controller" connected (SDL), with a gyroscope
hid: controller "Steam Controller" connected (SDL), Steam Input's
hid: "Steam Controller": motion only, its buttons come through Steam Input's pad
hid: motion controls from "Steam Controller"

(Those runs predate 41d904e8, so the first line reads Valve's controllers (not the Steam Deck's) taken out... with the current code. Steam's stand-in pad sometimes comes through as #SettingsController_SteamController, Steam's untranslated name.)

Started on its own with Steam closed: there's no list and no stand-in pad, so none of this runs, and the real pad plays as before, buttons and gyro:

hid: controller "Steam Controller" connected (SDL), with a gyroscope
hid: motion controls from "Steam Controller"
hid: 1 controller through SDL

Focus switches: three switches to another window and back on the nightly plus this change, with no re-arm (its gyroscope stopped changing) in the log. That doesn't answer the IMU question yet: on Hyprland, Steam's controller log shows no layout change during those switches, so Steam likely never moved to a gyro-less layout. A run that forces one (the Steam overlay, or a Deck in Game Mode) is next.

tests/test_steam_pads.py, test_hd_rumble.py, test_gyro_rearm.py, test_touchpad_menu.py and test_motion.py pass.

Not tested on Windows. The issue was reported there too and the code path is the same.

Fixes #1897. Started from Steam, SDL gets Steam's controller ignore list (`SDL_GAMECONTROLLER_IGNORE_DEVICES`), which has Valve's own pads in it, along with `SDL_GAMECONTROLLER_ALLOW_STEAM_VIRTUAL_GAMEPAD=1`. So SDL only opens Steam Input's stand-in pad. That pad has no gyroscope, so motion controls found nothing. - `host/steam_pads.h` (new, no SDL in it): takes Valve's `0x28de` entries out of the list, except the Steam Deck's built-in controls (`0x28de/0x1205`), and keeps the rest in order. The Deck's stay because SDL's Steam Deck driver resets their trackpad and button settings as it opens them, and that isn't tested beside Steam Input in Game Mode yet. A list from a file (`@path`) or one too long for the buffer is left as it is. Also the rule for when a pad gives its motion only. - `host/hos_sdl.c` / `.h`: three optional calls, `SDL_Get(Gamepad|GameController)Vendor`, `SDL_Get(Gamepad|GameController)SteamHandle` and `SDL_SetHintWithPriority` (SDL 2.30+ and SDL3 3.2+). The list is set with override priority, since Steam's environment variable beats a plain `SDL_SetHint`. An SDL without all three leaves the list as Steam set it, so a real pad and its stand-in never both play. - `host/pad_sdl.c`: while a stand-in pad (one with a Steam handle) is open, the real Valve pad gives its motion only. Its buttons and sticks come through the stand-in as the player's Steam layout maps them, so they aren't counted twice, and its rumble goes through Steam too. Its presses still mark it the pad used last, so `motion_poll` reads its gyro. It isn't counted in the controller total or used for the prompts name. When no stand-in is open, the real pad plays as before. A real Valve pad that SDL opens with no motion sensors (an SDL with no driver for it) is logged once, so the next person with #1897 sees why. - `tests/test_steam_pads.py`: the list filter (the Deck's entry kept) and the motion-only rule. **SDL requirement:** gyro only comes through if the SDL the game loads has a driver that reads the pad's motion sensors. CachyOS's `sdl3` 3.4.18 and 3.4.20 and Steam's bundled SDL3 do for the 2026 puck. One without it gets this line and no gyro, and buttons work as before: ``` hid: "Steam Controller": no motion sensors through this SDL, so Motion controls can't read it; its buttons come through Steam Input's pad ``` ## Testing Linux (CachyOS, Hyprland), 2026 Steam Controller (wireless puck). Not tested with the original Steam Controller. Started from Steam: gyro works and each input registers once. The log: ``` hid: Valve's controllers taken out of Steam's ignore list, for their motion sensors hid: controller "Steam Controller" connected (SDL), with a gyroscope hid: controller "Steam Controller" connected (SDL), Steam Input's hid: "Steam Controller": motion only, its buttons come through Steam Input's pad hid: motion controls from "Steam Controller" ``` (Those runs predate 41d904e8, so the first line reads `Valve's controllers (not the Steam Deck's) taken out...` with the current code. Steam's stand-in pad sometimes comes through as `#SettingsController_SteamController`, Steam's untranslated name.) Started on its own with Steam closed: there's no list and no stand-in pad, so none of this runs, and the real pad plays as before, buttons and gyro: ``` hid: controller "Steam Controller" connected (SDL), with a gyroscope hid: motion controls from "Steam Controller" hid: 1 controller through SDL ``` Focus switches: three switches to another window and back on the nightly plus this change, with no re-arm (`its gyroscope stopped changing`) in the log. That doesn't answer the IMU question yet: on Hyprland, Steam's controller log shows no layout change during those switches, so Steam likely never moved to a gyro-less layout. A run that forces one (the Steam overlay, or a Deck in Game Mode) is next. `tests/test_steam_pads.py`, `test_hd_rumble.py`, `test_gyro_rearm.py`, `test_touchpad_menu.py` and `test_motion.py` pass. Not tested on Windows. The issue was reported there too and the code path is the same.

rivyr commented

2026-11-11 21:32:38 +00:00

(Migrated from github.com)

Thanks for working on this. I hit the same thing with a 2026 Steam Controller (puck) on Garuda Linux and built a fix before I saw this PR, so here are a couple of things I ran into.

SDL version. This approach needs an SDL that has a driver for the 2026 controller. My system SDL3 is 3.4.18 (Arch package), and as far as I can tell it doesn't have one. There's no SDL_JOYSTICK_HIDAPI_STEAM_TRITON hint in the library, only the original Steam Controller and the Deck. With an SDL like that, taking 28de out of the ignore list wouldn't give SDL a pad with a gyro. Your log shows "Steam Controller" connected (SDL), with a gyroscope, so it looks like CachyOS ships a newer SDL. Do you know which version it is? It might be worth falling back gracefully, or mentioning the requirement, for distros and the AppImage's SDL that don't have the driver yet.

SDL's driver and Steam both managing the controller. I did the same thing in another recompilation port, where SDL opened the real Valve controller next to Steam Input. SDL's driver and Steam both set lizard mode and the IMU setting, and I got gyro dropouts. Separately, Steam turns the controller's IMU off whenever the active layout uses no gyro, and Alt+Tab can switch layouts. When that happens, the reports keep coming with the IMU values frozen rather than zeroed, so the gyro just stops. The test_gyro_rearm path would catch that, but only after 1.2 s.

What I did instead. I left the ignore list alone and read the controller's own HID reports through SDL's hidapi. It only reads; Steam keeps managing the controller. It feeds the gyro and accelerometer to motion_poll only when no SDL pad has motion. It watches the IMU's own timestamp, and if that stops moving for 250 ms it resends the IMU-mode feature report (01 87 03 30 18 00), only to the puck interface that's actually reporting, since sending to an empty slot blocks for about 150 ms. That means it doesn't need a Triton driver in SDL, and SDL never opens the controller. It's Linux only, about 300 lines in a new host/steam_triton.c, plus small hidapi wrappers in hos_sdl.c and a parser test. It works on my machine with v2.1.0 and SDL3 3.4.18, both on the puck and after Alt+Tab.

I don't want to open a competing PR. If it's useful, I'm happy to share the branch, or to open it as a fallback for when SDL has no Triton driver, whichever you and the maintainers prefer.

Thanks for working on this. I hit the same thing with a 2026 Steam Controller (puck) on Garuda Linux and built a fix before I saw this PR, so here are a couple of things I ran into. SDL version. This approach needs an SDL that has a driver for the 2026 controller. My system SDL3 is 3.4.18 (Arch package), and as far as I can tell it doesn't have one. There's no SDL_JOYSTICK_HIDAPI_STEAM_TRITON hint in the library, only the original Steam Controller and the Deck. With an SDL like that, taking 28de out of the ignore list wouldn't give SDL a pad with a gyro. Your log shows "Steam Controller" connected (SDL), with a gyroscope, so it looks like CachyOS ships a newer SDL. Do you know which version it is? It might be worth falling back gracefully, or mentioning the requirement, for distros and the AppImage's SDL that don't have the driver yet. SDL's driver and Steam both managing the controller. I did the same thing in another recompilation port, where SDL opened the real Valve controller next to Steam Input. SDL's driver and Steam both set lizard mode and the IMU setting, and I got gyro dropouts. Separately, Steam turns the controller's IMU off whenever the active layout uses no gyro, and Alt+Tab can switch layouts. When that happens, the reports keep coming with the IMU values frozen rather than zeroed, so the gyro just stops. The test_gyro_rearm path would catch that, but only after 1.2 s. What I did instead. I left the ignore list alone and read the controller's own HID reports through SDL's hidapi. It only reads; Steam keeps managing the controller. It feeds the gyro and accelerometer to motion_poll only when no SDL pad has motion. It watches the IMU's own timestamp, and if that stops moving for 250 ms it resends the IMU-mode feature report (01 87 03 30 18 00), only to the puck interface that's actually reporting, since sending to an empty slot blocks for about 150 ms. That means it doesn't need a Triton driver in SDL, and SDL never opens the controller. It's Linux only, about 300 lines in a new host/steam_triton.c, plus small hidapi wrappers in hos_sdl.c and a parser test. It works on my machine with v2.1.0 and SDL3 3.4.18, both on the puck and after Alt+Tab. I don't want to open a competing PR. If it's useful, I'm happy to share the branch, or to open it as a fallback for when SDL has no Triton driver, whichever you and the maintainers prefer.

Joey-Magnus (Migrated from github.com) reviewed

2026-11-11 21:46:30 +00:00

Joey-Magnus (Migrated from github.com) left a comment

My concern is the Steam Deck, which is tier 1 in docs/workflow.md. Its built-in controls are 0x28de/0x1205, in the same ignore list, so host/pad_sdl.c:110 takes them out too. Under Steam, Game Mode included, SDL's HIDAPI Steam Deck driver then opens them alongside Steam Input. On open, that driver sends ID_CLEAR_DIGITAL_MAPPINGS and sets both trackpads to TRACKPAD_NONE, then repeats every ~200 reads. That may be harmless, and it would give Deck players gyro, but it was only tested with a Steam Controller on a desktop. Could you test on a Deck in Game Mode (trackpads, Steam/QAM buttons, gyro, inputs counted once)? If not before merge, keep 0x28de/0x1205 in the list for now.

The design is careful. The list filter is pure and tested, Steam's list is only changed when the SDL has all three calls, the motion-only pad is left out of the count, rumble and the prompts name, and `motion_poll` only picks pads with sensors, so the stand-in never wins. CI is green. My concern is the Steam Deck, which is tier 1 in `docs/workflow.md`. Its built-in controls are `0x28de/0x1205`, in the same ignore list, so `host/pad_sdl.c:110` takes them out too. Under Steam, Game Mode included, SDL's HIDAPI Steam Deck driver then opens them alongside Steam Input. On open, that driver sends `ID_CLEAR_DIGITAL_MAPPINGS` and sets both trackpads to `TRACKPAD_NONE`, then repeats every ~200 reads. That may be harmless, and it would give Deck players gyro, but it was only tested with a Steam Controller on a desktop. Could you test on a Deck in Game Mode (trackpads, Steam/QAM buttons, gyro, inputs counted once)? If not before merge, keep `0x28de/0x1205` in the list for now.

dylmart commented

2026-11-11 22:09:30 +00:00

(Migrated from github.com)

@Joey-Magnus Good catch. I don't want to change Deck behavior without testing it, so 0x28de/0x1205 stays in the list now and only the Steam Controller entries come out (41d904e8). I have a Deck and will test Game Mode (trackpads, Steam/QAM, gyro, inputs counted once). If it holds up, a follow-up PR takes 0x1205 out.

@Joey-Magnus Good catch. I don't want to change Deck behavior without testing it, so 0x28de/0x1205 stays in the list now and only the Steam Controller entries come out (41d904e8). I have a Deck and will test Game Mode (trackpads, Steam/QAM, gyro, inputs counted once). If it holds up, a follow-up PR takes 0x1205 out.

dylmart commented

2026-11-11 22:09:31 +00:00

(Migrated from github.com)

@rivyr Thanks, this is useful. On SDL: my Steam run used CachyOS's sdl3 3.4.18-1.1 and the no-Steam run 3.4.20-1.1. Both opened the puck on hidraw with gyro and accelerometer, and so did Steam's bundled SDL3 in a standalone probe. Not sure why yours didn't, so a requirement note makes sense. On dropouts: fair point. I didn't see any, but my sessions were short and I didn't Alt+Tab into a layout without gyro. Your read-only approach avoids the two-managers problem entirely, so I'd be glad to see it as a fallback, or as the main fix if the maintainers prefer it.

hckrman101 (Migrated from github.com) reviewed

2026-11-11 22:17:51 +00:00

hckrman101 (Migrated from github.com) left a comment

Reviewed at 41d904e8 (the Deck-entry commit on top of d64432ea). Code reads correct to me and I agree with Joey-Magnus's read of the design. His Steam Deck concern is addressed: 0x28de/0x1205 now stays in the list (steam_pads.h, with a test), so Game Mode is unchanged until you've tested it.

What's still open:

rivyr's SDL point is not answered in the code. The change only helps with an SDL that has a driver for the 2026 controller; with one that doesn't, the list is loosened for nothing (harmless, the real pad just gives no motion, but silent). A one-line log when a Valve pad opens without sensors, or a note in the PR/docs about the SDL requirement, would help the next person who hits #1897. Your CachyOS 3.4.18 run shows it works there, so this is about other distros and the AppImage's SDL.
rivyr's second point is a real risk and I'd like the maintainers' view: with this approach SDL's driver and Steam both manage the pad (lizard mode, IMU setting), and Steam turns the IMU off for a layout with no gyro, after which reports keep coming with frozen values. motion_poll's 1.2 s re-arm covers it, but gyro will stutter for that long after a layout switch/Alt+Tab. Your sessions were short, so a longer run with an Alt+Tab into a gyro-less layout would show whether it's livable. rivyr offered a read-only hidapi fallback; whether that should be the main fix is NotRexed's call.
The Steam Controller entries (not only the Deck) are the same kind of change: SDL's driver now opens them next to Steam Input. It's tested on one pad (the 2026 puck), not on the older Steam Controller. Fine to say so in the PR.

Nits:

The PR description still says Valve's 0x28de entries come out; since 41d904e8 the Deck's 0x1205 stays. Worth a sentence, and the log line in the Testing section differs from the one in the code now ("not the Steam Deck's").
Not tested on Windows, as the description says. Nothing I see in the Windows path (GetProcAddress for the three calls, getenv for an ASCII list) is a problem.

CI: the Windows and AppImage builds pass; the Python source checks and the title check were still pending when I looked. Decision on merge stays with NotRexed given the two open questions above.

Reviewed at 41d904e8 (the Deck-entry commit on top of d64432ea). Code reads correct to me and I agree with Joey-Magnus's read of the design. His Steam Deck concern is addressed: `0x28de/0x1205` now stays in the list (`steam_pads.h`, with a test), so Game Mode is unchanged until you've tested it. What's still open: - rivyr's SDL point is not answered in the code. The change only helps with an SDL that has a driver for the 2026 controller; with one that doesn't, the list is loosened for nothing (harmless, the real pad just gives no motion, but silent). A one-line log when a Valve pad opens without sensors, or a note in the PR/docs about the SDL requirement, would help the next person who hits #1897. Your CachyOS 3.4.18 run shows it works there, so this is about other distros and the AppImage's SDL. - rivyr's second point is a real risk and I'd like the maintainers' view: with this approach SDL's driver and Steam both manage the pad (lizard mode, IMU setting), and Steam turns the IMU off for a layout with no gyro, after which reports keep coming with frozen values. `motion_poll`'s 1.2 s re-arm covers it, but gyro will stutter for that long after a layout switch/Alt+Tab. Your sessions were short, so a longer run with an Alt+Tab into a gyro-less layout would show whether it's livable. rivyr offered a read-only hidapi fallback; whether that should be the main fix is NotRexed's call. - The Steam Controller entries (not only the Deck) are the same kind of change: SDL's driver now opens them next to Steam Input. It's tested on one pad (the 2026 puck), not on the older Steam Controller. Fine to say so in the PR. Nits: - The PR description still says Valve's `0x28de` entries come out; since 41d904e8 the Deck's `0x1205` stays. Worth a sentence, and the log line in the Testing section differs from the one in the code now ("not the Steam Deck's"). - Not tested on Windows, as the description says. Nothing I see in the Windows path (`GetProcAddress` for the three calls, `getenv` for an ASCII list) is a problem. CI: the Windows and AppImage builds pass; the Python source checks and the title check were still pending when I looked. Decision on merge stays with NotRexed given the two open questions above.

hckrman101 (Migrated from github.com) reviewed

2026-11-11 22:41:11 +00:00

hckrman101 (Migrated from github.com) left a comment

Re-reviewed at 11529114 (one new commit on top of 41d904e8, host/pad_sdl.c only).

Fixed: my point about an SDL with no driver for the pad. The log line when a Valve pad opens with no motion sensors is there now (said once, on the motion-only change), and it reads right: pads[i].motion is set from the gyro and accel checks at open, so the branch only fires for a pad that really has none. Thanks for that, and for the SDL versions in your reply to rivyr.

Still open:

rivyr's second point (SDL's driver and Steam both managing the pad, IMU turned off by Steam on a gyro-less layout, frozen values until the 1.2 s re-arm). You said your sessions were short; a longer run with an Alt+Tab into a layout without gyro is still the thing that would answer it. Whether the read-only hidapi route should be the main fix or a fallback is NotRexed's call, so the decision on merge stays with them.
The old Steam Controller entries are untested (only the 2026 puck). Fine to say so in the PR.

Nits:

The PR description is still the old one: it says Valve's 0x28de entries come out, but the Deck's 0x1205 stays since 41d904e8, and the Testing log doesn't show the new no-sensors line. One sentence on each would do. A note on the SDL requirement (a build with a driver for the 2026 pad) would help whoever hits #1897 next.

CI: the Windows Vulkan build, AppImage, builder and Linux checks pass; the title check was still pending. Python source checks (windows-2022, part 2/2) fails in test_pcache_header_read.py (fopen deprecated, no fseeko) and test_psychov35.py (scanf deprecated), both compile errors in test fixtures this PR doesn't touch, so not from this change. No conflicts.

Re-reviewed at 11529114 (one new commit on top of 41d904e8, `host/pad_sdl.c` only). Fixed: my point about an SDL with no driver for the pad. The log line when a Valve pad opens with no motion sensors is there now (said once, on the motion-only change), and it reads right: `pads[i].motion` is set from the gyro and accel checks at open, so the branch only fires for a pad that really has none. Thanks for that, and for the SDL versions in your reply to rivyr. Still open: - rivyr's second point (SDL's driver and Steam both managing the pad, IMU turned off by Steam on a gyro-less layout, frozen values until the 1.2 s re-arm). You said your sessions were short; a longer run with an Alt+Tab into a layout without gyro is still the thing that would answer it. Whether the read-only hidapi route should be the main fix or a fallback is NotRexed's call, so the decision on merge stays with them. - The old Steam Controller entries are untested (only the 2026 puck). Fine to say so in the PR. Nits: - The PR description is still the old one: it says Valve's `0x28de` entries come out, but the Deck's `0x1205` stays since 41d904e8, and the Testing log doesn't show the new no-sensors line. One sentence on each would do. A note on the SDL requirement (a build with a driver for the 2026 pad) would help whoever hits #1897 next. CI: the Windows Vulkan build, AppImage, builder and Linux checks pass; the title check was still pending. `Python source checks (windows-2022, part 2/2)` fails in `test_pcache_header_read.py` (`fopen` deprecated, no `fseeko`) and `test_psychov35.py` (`scanf` deprecated), both compile errors in test fixtures this PR doesn't touch, so not from this change. No conflicts.

dylmart commented

2026-11-11 22:44:24 +00:00

(Migrated from github.com)

@hckrman101 Thanks for the re-review. The PR description is updated: the Deck's 0x1205 stays, the no-sensors log line and the SDL requirement are in, and it says only the 2026 puck is tested, not the original Steam Controller.

On the IMU question, I don't have an answer yet. I ran a session on the nightly plus this change and switched to another window and back three times, and the log shows no re-arm. But this machine runs Hyprland, and Steam's controller log shows no layout change during those switches, so Steam likely never moved to a gyro-less layout. I'm not counting it as a pass. Next I'll force a layout change with the Steam overlay on desktop and with Steam/QAM on a Deck in Game Mode, and post what the log shows.

That session turned up a separate bug: with the game behind another window, the buttons stop but the gyro keeps turning the camera, because GetSixAxisSensorStates doesn't check the window. It's older than this PR, so it has its own: #2542.

@hckrman101 Thanks for the re-review. The PR description is updated: the Deck's `0x1205` stays, the no-sensors log line and the SDL requirement are in, and it says only the 2026 puck is tested, not the original Steam Controller. On the IMU question, I don't have an answer yet. I ran a session on the nightly plus this change and switched to another window and back three times, and the log shows no re-arm. But this machine runs Hyprland, and Steam's controller log shows no layout change during those switches, so Steam likely never moved to a gyro-less layout. I'm not counting it as a pass. Next I'll force a layout change with the Steam overlay on desktop and with Steam/QAM on a Deck in Game Mode, and post what the log shows. That session turned up a separate bug: with the game behind another window, the buttons stop but the gyro keeps turning the camera, because `GetSixAxisSensorStates` doesn't check the window. It's older than this PR, so it has its own: #2542.

dylmart commented

2026-11-12 02:35:23 +00:00

(Migrated from github.com)

@Joey-Magnus Update on the Deck test: I couldn't get the game running on my Deck. The nightly hangs the GPU as soon as a save loads (ring gfx_0.0.0 / comp timeouts in the kernel log), which looks like the hangs collected in #1000 rather than anything in this PR. I'll try again another time, but probably not soon, so the Deck's 0x1205 should stay in the list for now, as it is.

@Joey-Magnus Update on the Deck test: I couldn't get the game running on my Deck. The nightly hangs the GPU as soon as a save loads (`ring gfx_0.0.0` / `comp` timeouts in the kernel log), which looks like the hangs collected in #1000 rather than anything in this PR. I'll try again another time, but probably not soon, so the Deck's `0x1205` should stay in the list for now, as it is.