gamemax-sigma520-linux

Linux driver for the GAMEMAX SIGMA 520 Digital air cooler's CPU temperature display. The official GameMax software is Windows-only; this reverse-engineered driver reads your real CPU temperature from hwmon and pushes it to the cooler's LCD over raw USB HID, no Windows or Wine required.

The "card reader" gotcha

Plug the cooler in and run lsusb — you will not see anything called GameMax:

Bus 001 Device 006: ID 5131:2007 MSR MSR-101U Mini HID magnetic card reader

That's it. 5131:2007 is a generic HID controller chip reused across dozens of unrelated cheap USB gadgets (card readers, relay boards, and - as it turns out - budget cooler/case LCD displays). The vendor string was never customized, so Linux reports whatever the chip's silicon vendor originally built it for. If your device shows up this way, you're probably in the right place.

This exact chip also powers the LCDs on at least a VEVOR AIO, a Redragon CC-1013, a ValueTop Tempest DF6, and a Jonsbo TH240 - see Related projects. Each one implements a different protocol on top of the same chip, so drivers are not interchangeable across brands.

Hardware

• USB 5131:2007, no custom product string exposed.
• Full-speed USB HID device, single 64-byte OUT report, no Report ID declared in the HID report descriptor (confirmed via HIDIOCGRDESC).
• Data cable is the cooler's internal 9-pin USB 2.0 header (same cable that also carries the display's power).

Protocol

Reverse-engineered by bisection (no USB capture, no Windows machine involved - see How it was found):

Byte	Meaning
0	"active" flag - any non-zero value works, no specific magic byte required
1	CPU temperature, whole degrees Celsius, plain binary (0x2a = 42°C)
2-63	unused

No Report ID prefix byte (unlike the VEVOR and Redragon devices, whose descriptors do declare Report IDs - check tools/hid_descriptor.py on your own device before assuming this driver applies as-is). No checksum, no handshake, no opcode beyond "byte 0 is non-zero". The display blanks itself about 30 seconds after the last packet, so it needs a keepalive loop, not a one-shot write - this driver refreshes every 3 seconds, well inside that margin.

Install

Requires Python 3, a Linux kernel with hidraw/usbhid, and k10temp (AMD) or coretemp (Intel) loaded - both are stock kernel modules, nothing extra to install for the sensor side.

git clone https://github.com/devloadingbr/gamemax-sigma520-linux.git
cd gamemax-sigma520-linux
./install.sh

install.sh needs sudo for the udev rule and the systemd unit. It:

1. Installs a udev rule granting the plugdev group access to 5131:2007 hidraw nodes.
2. Adds your user to plugdev.
3. Copies the driver to /opt/gamemax-sigma520/.
4. Installs and enables a system systemd service (multi-user.target), so the display comes back on at boot even before any graphical login - not a systemd --user unit, which would depend on an active session.

Check it's running:

systemctl status gamemax-sigma520-display.service

If you were just added to plugdev for the first time, log out and back in once.

Troubleshooting

Service log shows "cooler hidraw device not found" (journalctl -u gamemax-sigma520-display.service) Confirm it's actually enumerating: lsusb | grep 5131:2007. If nothing shows up, the internal 9-pin USB 2.0 header cable is probably not fully seated - these headers are easy to misalign by one pin, which gives the display power (fan spins, screen lights up) without a working data connection. Reseat it.

Permission denied opening the hidraw device Check ls -l /dev/hidraw* for a 5131:2007 entry - it should be owned by group plugdev or tagged uaccess (udevadm info /dev/hidrawN | grep uaccess). If you were just added to plugdev, log out and back in - group membership doesn't apply to an already-open session.

"no CPU temperature sensor found" Check ls /sys/class/hwmon/*/name. The daemon looks for k10temp (AMD), coretemp (Intel), or zenpower. If your CPU exposes temperature under a different hwmon driver name, add it to the tuple in find_cpu_temp_path() in gamemax_sigma520_display.py.

Display shows a number, but it's wrong, or nothing happens at all Your unit's firmware revision may map the bytes differently than documented here. Run tools/hid_descriptor.py against your device first - if the descriptor differs from the one in this README, this driver doesn't apply as-is; use tools/hid_probe.py to re-run the bisection for your hardware.

Service keeps restarting journalctl -u gamemax-sigma520-display.service -f. The daemon retries every 5s on error by design (e.g. cable unplugged mid-session), so a few restarts right after an unplug/replug is expected, not a bug.

Uninstall

sudo systemctl disable --now gamemax-sigma520-display.service
sudo rm /etc/systemd/system/gamemax-sigma520-display.service /etc/udev/rules.d/99-gamemax-sigma520.rules
sudo rm -rf /opt/gamemax-sigma520
sudo systemctl daemon-reload

Dev tools

tools/ has the two scripts used to reverse-engineer this protocol, kept for anyone with an adjacent GameMax/rebrand SKU that doesn't match this exact mapping:

• hid_descriptor.py - dumps the raw HID report descriptor via the HIDIOCGRDESC ioctl (stdlib only, no hidapi dependency). Tells you whether your device declares a Report ID before you try anything else.
• hid_probe.py - interactive REPL against a hidraw node: send, fill, range (byte-range bisection), and a raw first-byte scan. This is how the byte 0 / byte 1 mapping above was found - by bisecting which byte ranges of an all-zero 64-byte packet needed to be non-zero to move the display off 0°.

How it was found

No Windows machine was available, so this wasn't captured from the official software - it was found by bisection directly on Linux: fill the whole 64-byte report with a test value (confirms the value round-trips somewhere), then binary-search which byte range still reproduces the result when zeroing out the rest, down to individual bytes. Full walkthrough in the commit history / issue-style notes is intentionally not needed here since the protocol turned out to be this small - two bytes, no checksum.

Related projects

Same 5131:2007 chip, different products, different protocols - worth checking if your hardware doesn't match this driver:

• vevor-lcd - VEVOR AIO, 65-byte report with Report ID, clock + dual temp
• redragon-linux-hid-temp - Redragon CC-1013, 3-byte report [00][AA][temp]
• value-top-display - ValueTop Tempest DF6, closed-source binary
• lcus-hid-relay - background on the generic LCUS HID board family this chip belongs to

License

MIT - see LICENSE.

Disclaimer

Unofficial, community reverse-engineered driver. Not affiliated with or endorsed by GameMax. It only ever writes to the device's Output HID report; no firmware flashing, no Feature report writes. Worked reliably in testing, but as with anything reverse-engineered from a black box: use at your own risk.