[elieteyssedou]

What and why

Fixes #1218. Builds on #859: its commits come first in this branch until it lands. #1534 does the same as #859; if that one lands instead, this moves onto it.

Two Switch Pro Controllers over USB play as one player on the Mac: GameController lists one controller, IOKit has both devices, and their USB serial numbers match (over Bluetooth both are listed). GameController gives a controller no HID identity, so its one controller cannot be tied to one of the two devices.

In dm/host:

• pad_hid_mac.h keeps the devices GameController lists (g_hidpads_gc), unread, instead of dropping them, so that the pads of each model can be counted, by name (vendorName is the HID product string, as Mac: a HID pad GameController says it lists waits two seconds for it, and is read as HID if it never comes #859 matches them).
• front_mac.m: when IOKit has at least two pads of a model and more than GameController lists, after a 3 s wait for a pad not listed yet (pad_dupes_want, pad_hid.h), every pad of that model is read here, a player each, by USB location. GameController's controllers of that model are left unread. When GameController lists them all again, they go back to it.
• A Pro Controller is read from its report 0x30 (pad_pro.h), with its motion through motion_pro_mac.h; any other model from its HID elements, as pad_hid.h reads them.
• A Pro Controller's sticks take its own calibration from SPI flash (subcommand 0x10: the user's at 0x8010 when its magic is there, else the factory's at 0x603D). Without an answer, each axis measures its own rest and reach.
• DM_PAD_IDENTICAL=0 turns it off.

Limits: such pads have no rumble or player lights, and Home does not quit from them. Another model's buttons follow 8BitDo's numbering unless DM_HID_MAP says otherwise; only Pro Controllers were run this way.

Checked

• Tests: make -C dm/host/tests GAME=0400C3F00006E000 run passes: t_pad_pro 55 checks (report 0x30, the SPI read, both calibrations), t_pad_hid 27 (when a model is read here). dm/tools/tests/test_docs.py passes.
• front_mac.m compiles with -Wall -Wextra with no new warning.
• Game run: Mario Kart World (0400C3F00006E000) 1.8.0 as a Mac app, 33 minutes of two-player split-screen races, from a local build that also carried Indirect-count multi-draws are copied when their pass opens: Mario Kart World's scene passes are no longer split for them #1179, Mario Kart World 1.8.0: image slots in the dimension the shader declares, and Ampere's fragment depth register #1292 and host/vi: HDR output for Switch 2 games on screens that can show EDR #1176:

Pads	What the log and the game showed
2 Pro Controllers, USB	Pro Controllers: GameController lists 1 of 2: reading them all from their HID reports; two players; one pad took its factory calibration, the other the user's
Pro Controller, Bluetooth	listed by GameController and read through it; the calibration read answers (checked with a standalone tool)
2 Xbox Wireless Controllers, Bluetooth	both listed by GameController; nothing read here

• A duplicate player found in that run (GameController's own Pro Controller joining too) is fixed; the fix builds and the tests pass.
• Device: M4 Pro, macOS 27, Xcode 27.2.
• scripts/regress.py: not run; the change is in the host's controller input only, with no shader, rendering or tool change.

Docs

• docs/reference/services.md: Identical controllers that GameController lists as one; python3 dm/tools/docs_symptoms.py run
• docs/playing.md, docs/env_switches.tsv
• No game files, keys or data extracted from a game in the change

🤖 Generated with Claude Code

[seedds]

Landed in 1ed28ed, reworked, with you credited as co-author. Thanks, the diagnosis and the decoder made this easy.

What changed from the PR:

• One mechanism, in pad_hid_mac.h, on its own HID manager. It counts IOKit's pads of each model (vendor and product ID) against GameController's controllers of it, and reads a model's pads with that model's reader: pad_pro.h for a Pro Controller, HID elements for others. The Pro Controller path no longer goes through motion_pro_mac.h's manager, which is unchanged. That also fixes a bug: DM_MOTION=0 or DM_MOTION_HID=0 stopped dm_motion_pro_start early, so the two Pros were never seen and Mac: two identical Pro Controllers over USB count as one, so a two-player game refuses them #1218 came back without a word in the log. Those switches now turn off only the gyro.
• Microsoft, Sony and Nintendo pads other than the Pro are never read this way. Since Mac: a HID pad GameController says it lists waits two seconds for it, and is read as HID if it never comes #859 landed, main keeps those vendors off the name match because their names don't match GameController's (a DualShock 4's HID product string is Wireless Controller). With the name-matched path, two DualShock 4s would have been read both through GameController and from IOKit. The Pro is matched by its product category instead.
• Unchanged from you: pad_pro.h and its tests, the calibration read, pad_dupes_want and the 3 s wait, the order by USB location, leaving GameController's controller unread, and the docs (now describing the new structure).

The reworked version builds and the host tests pass, but it hasn't run on real pads; I have no Pro Controllers here. Could you run two Pro Controllers over USB on current main, and check that each is a player of its own with its calibration? The log lines are now [hid] 'Pro Controller' (057e:2009) at USB location 0x…: GameController lists 1 of 2 pads of this model: read here, from its report 0x30. Please also try once with DM_MOTION_HID=0 to confirm the buttons still work. The push closed #1218; if it fails, I'll reopen it.

#1596 is next: I'll check it on top of this.