gamecontrollerDB for 8bitdo Ultimate 3 Wireless Controller for Xbox

[sdornan]

Problem

The 8BitDo Ultimate 3 Wireless Controller for Xbox (launched 2026-08-31) is not autoconfigured by RetroBat. In 2.4G dongle mode the pad works at the OS level — Windows binds it under Xbox Peripherals and it responds correctly in joy.cpl — but EmulationStation never sees it.

The cause is that its USB product ID is newer than every shipping SDL release:

• On Windows the dongle enumerates as USB\VID_2DC8&PID_2072, i.e. SDL GUID 03000000c82d00007220000000000000.
• 0x2072 is absent from SDL's built-in mapping table. Verified against release-3.2.30 — the SDL3 build shipped in system/tools/SDL3_x64.dll — and also release-3.4.0 and release-3.4.2.
• It is absent from upstream SDL_GameControllerDB.
• It is absent from the Linux xpad table, which does list the siblings 0x200f, 0x310a and 0x310b.
• SDL carries exactly one Ultimate 3 product ID, 0x202f, and its own comment marks it // mode switch to BT. That is a different switch position from the 2.4G dongle, and it exists only on SDL main (3.5.0-dev), so no released SDL covers either mode.

With no SDL match and no entry in system/tools/gamecontrollerdb.txt, autoconfiguration has nothing to work from.

Change

Adds one mapping line to system/tools/gamecontrollerdb.txt, grouped with the other Ultimate entries in the # RetroBat modified block:

03000000c82d00007220000000000000,8BitDo Ultimate 3 Wireless Controller for Xbox,...,platform:Windows,

The GUID was derived with the standard SDL little-endian bus/VID/PID packing and the formula was validated by regenerating four GUIDs already present in this file (Pro 3 0x6009, Ultimate 2C 0x310a, Ultimate 2 0x310b, Ultimate 2 Wireless 0x6012) and confirming exact matches.

The button layout mirrors the sibling Ultimate entries already in this file — Ultimate 2C (0x310a), Ultimate 2 (0x310b) and Ultimate FC40 (0x3106) — which all share the standard Xbox-mode ordering.

Verification

Confirmed working on hardware: with this line added to system/tools/gamecontrollerdb.txt, RetroBat picks the controller up. Without it, the pad is not detected at all despite working correctly in joy.cpl.

The Ultimate 3's Share button and four paddles are deliberately left unmapped, since their indices in this mode were not verified.

🤖 Generated with Claude Code

[sdornan]

Correcting my own description above — some of the reasoning in it is wrong, and I'd rather flag it than have you review it as written.

I tested with SDL2 Gamepad Tool (SDL 2.32.10), controller on its 2.4G dongle. SDL reports:

"Xbox One Controller", 0300938d5e040000ff02000000007200 (mapping available)

That decodes to vendor 0x045e (Microsoft), product 0x02ff, driver signature byte 0x72 = 'r' (RAWINPUT) — i.e. the XBOXGIP software PID, which SDL already has in controller_list.h as "Microsoft Xbox One Controller with XBOXGIP driver on Windows". The controller is Xbox-licensed and binds to xboxgip.sys, showing under "Xbox Peripherals" in Device Manager.

So these two claims in the description are wrong:

"its USB product ID is newer than every shipping SDL release" — 2dc8:2072 is genuinely absent from SDL, but SDL never sees that ID on the RawInput/GIP path.
"SDL has no mapping for it" — stock SDL maps it fine out of the box.

What is still true and verified on hardware: RetroBat does not detect the controller at all, and adding this line to gamecontroller.txt makes it work. The 2dc8:2072 GUID only appears on the DirectInput path, which is evidently the path RetroBat is using here.

So the mapping does fix it, and given this file is the dinput mapping DB it may be exactly the right place. But you're better placed than me to judge whether the real fix is elsewhere — a controller that stock SDL handles via RawInput isn't being picked up by RetroBat, which would affect any Xbox-licensed pad, not just this model. Happy to close this if you'd rather chase that instead.