[nesbox]

The sokol layer's Windows backend reads what XInput reaches — the Xbox family, the Steam Deck's virtual pad, an 8BitDo in its X mode. Three of the five pad families are not XInput devices at all: DualShock 4 and DualSense, Switch Pro and Joy-Con, and an 8BitDo in its S mode. Today's SDL build reads them through its HIDAPI drivers, so switching the desktop to the sokol layer without this would take those pads away from Windows players. This is that half back.

The route was decided by a spike, not a preference. Two PowerShell lines against Windows.Gaming.Input on the owner's machine, with the S-mode 8BitDo connected: one raw controller and nothing in Gamepad.Gamepads. Windows has no standard layout for that family, and GameInput would have nothing to place it with. For PlayStation there is no pad on the bench at all, so taking GameInput there would have stacked two unverified things — Microsoft's table and our integration — with no way to see either fail. So: our own readers, both families, decoding ported from the vendored SDL rather than derived. The layouts, the report ids, the hat nibble and the Bluetooth CRC are proven code re-hosted; only what the machine reads is taken.

A reader is report + length → bits + right stick — no handle, no platform, no timing. src/system/sokol/sgamepad_hid.h, included by the Windows branch. That is what makes the one part of a platform backend that otherwise needs the pad in hand testable: tests/sgamepad_hid.c drives them from reports, on every platform, and a sgamepad-hid-test target runs it in CI. It was worth its keep — it caught the Switch stick offsets being two bytes early and the Bluetooth packet offsets being out by the length byte before any hardware was involved.

On Windows, devices are found with SetupDiGetClassDevs and opened by the vendor and product ids the readers know, which leaves a wheel or a pad in a vendor mode with its own layout unclaimed rather than read as buttons nobody pressed. One overlapped ReadFile is left outstanding and looked at once a frame, so nothing blocks on a pad that has gone quiet; the device list is walked at startup, when a pad stops answering, and on a one-second clock, because reading a device's ids means opening it. A pad that reports at all takes its slot: these families send while they are held and go quiet on the table, where an XInput pad answers a poll whether anyone has picked it up. Over Bluetooth a PlayStation pad stops streaming unless the host asks it to go on, so the layer sends SDL's tickle when a pad in its extended report mode has been quiet — without the CRC, since a packet whose sum adds up is a real effects report, which is a pad being changed rather than one being asked to keep talking. hid and setupapi come with every Windows SDK; no redistributable, no gameinput.lib.

Verified, and not. The readers run under ctest -R sgamepad (15 scenarios, both connections, both DualSense layouts, the CRC checked against SDL's own over every length and prefix). The macOS sokol target builds and links with the new header. The Windows device layer has been type-checked against stub headers only — it has never been compiled by a Windows compiler and never run; the CI step this PR adds is its first real compile, and the bench its first run. The Switch 0x3F-only reader and the wired pad that may want the full 0x30 report are open until a pad answers.

Two reviews, and the second one mattered more. The first found four real bugs: the DualSense sends its state report in two layouts and only one was read, so a pad in its default mode parsed its trigger bytes as the hat and face buttons; the Windows device table had two backends writing the same entries, so an Xbox pad and a DualSense together meant one invisible and the other's input; the keepalive was a real effects report; and the left stick steered nothing. The second found the worst of them, which the first had looked at and passed: every vertical axis was inverted, on both sticks and all three families. The readers negated the y they read, and the reason was written down in the header as a premise rather than checked — and the test table had been built on the same premise, so it agreed with the code. What settles it is SDL's own documented convention (SDL_gamecontroller.h: an axis runs from -32768, up/left, to 32767, down/right) and what its backends do to reach it. A pad's sticks now point the way the pad is pushed, checked by hand at the byte level rather than by re-reading the reader.

Desktop still ships the SDL layer, so nothing user-visible changes until the migration change turns this one on.

🤖 Generated with Claude Code