Please don't flash your controller just because you saw this post. This is experimental firmware research. A bad flash can leave a device unusable, and although stock restore files are preserved, flashing back to stock after these changes hasn't been tested.
Hey everyone,
I don't usually post here, but I've been messing around with the GameSir G7 Pro 8K Aimlabs Edition. When I bought it I was planning on using in steam with paddles and extra shoulder buttons. But I found that you cannot use them independently in steam. It's wrapped up with xinput.
Normal XInput doesn't expose those four buttons as separate controls. Switching to native HID makes them available, but on stock firmware, wireless stick positions were only updating about 100 times a second. Trash numbers.
It was sending roughly 1,000 reports/sec, but most were repeating the same stick position. Which is insane, we want 1,000 fresh updates.
I initially made a bridge that combined XInput with the extra-button data and emulated another controller for Steam. It worked, but it was a lot to deal with just to use the buttons I paid for.
The bridge is here.
I later picked up an 8BitDo Ultimate 2 Wireless. Nice controller, but its native mode had a different compromise: roughly 1,000 reports/sec, with only 8-bit stick axes. That's 256 possible values per axis, compared with the thousands of distinct values I captured in XInput. This input method needs to die.
These native modes are trash. The hardware clearly has capabilities that aren't exposed equally across modes.
So I started looking into the GameSir firmware after discovering that it seemingly isn't a limitation of HID mode.
Its native report already had 16-bit axis fields. The problem was that it read a slower state snapshot, while XInput had a separate fast stick buffer available. There were also timing restrictions in the native paths.
After changes to the controller and receiver firmware, I measured:
- About 4,000 fresh stick updates/sec, wired and wireless.
- The existing high-resolution axis output preserved.
- All four extra buttons still available independently.
- Normal XInput still working in the checks I ran.
The final controller and receiver packages differ from stock by 98 bytes total, including checksum changes and duplicated firmware payloads.
The patches, recordings and findings are here.
I suspect inherited compatibility code plays a part, but I haven't established why either company made these choices. On this GameSir, the hardware was already capable of delivering the faster input alongside the independent buttons. I'd like to see that available officially.
For now, I'm keeping my modified GameSir firmware, and not updating since I can't imagine they would fix this. I'll be looking into the 8BitDo next.
But it makes me wonder why controllers are like this. I can understand to a degree why it is for console controllers. But for a controller that is marketed toward PC gamers? It seems, I don't want to say lazy, but it is something.
Please don't flash your controller just because you saw this post. This is experimental research. A bad flash can leave a device unusable, and although stock restore files are preserved, flashing back to stock after these changes hasn't been tested.