What Hypercolor controls (and what it doesn't)

Hypercolor is an RGB orchestration engine: it sends lighting frames to physical hardware in real time. Before spending an hour troubleshooting a device that cannot work yet, it helps to know exactly which hardware is in scope today and which is not.

#What Hypercolor controls

Hypercolor drives hardware through two transport layers.

USB/HID devices connect over USB and are discovered automatically when you plug them in, provided the udev rules are in place on Linux. Supported driver families today:

Network devices are discovered over your LAN (mDNS for most, a UDP multicast scan for Govee), then driven in real time over UDP or HTTP:

Bridged devices reach Hypercolor through another process rather than a driver of its own. The OpenRGB bridge is off by default. ROLI Blocks discovery is on by default (discovery.blocks_scan = true) but stays inert unless blocksd is running:

For the full list with every supported PID and device note, see the compatibility matrix.

#What Hypercolor does NOT control (yet)

#RAM RGB (non-ASUS)

ASUS Aura DRAM DIMMs are already supported: the asus_aura_smbus_dram driver ships today and drives them over SMBus on both Linux (via i2c-dev) and Windows (via PawnIO). Other DIMM vendors are not there yet. Corsair RAM (Dominator, Dominator Titanium) is researched and in the database with the wire protocol documented, but no driver has shipped, so non-ASUS DRAM lighting remains outside Hypercolor’s scope for now.

#GPU RGB

GPU RGB via SMBus is researched for several families (ASUS Aura GPU via ENE SMBus, EVGA Pascal/Turing/Ampere, Gigabyte GPU across four generations, and MSI Lovelace), with ASRock AMD GPUs further back at the Known stage. None have a shipping driver. The SMBus transport exists in the codebase; the per-vendor protocol implementations do not. Your GPU will not appear in hypercolor devices list.

#Blocked devices: Dygma Defy

The Dygma Defy (wired 0x0010 and wireless 0x0012) has a complete driver implementation in hypercolor-hal, covering the wire protocol, zone mapping, and RGBW color support. It is blocked, not missing. The stock Defy firmware does not expose a non-persistent direct LED streaming path that Hypercolor can use. The driver probes for a hypercolor.capabilities command and logs once per connection that live frame writes are being dropped. Until Dygma ships firmware support for external RGB control over the Focus protocol, the Defy will appear as discovered but unresponsive to lighting.

#Devices in “Researched” or “Known” state

The compatibility matrix uses five status levels:

If your device is Researched or Known, it is a candidate for a contributed driver. See adding a driver if you want to accelerate it.

#Devices controlled by another RGB manager

If openrazer daemon, OpenRGB, Aura Sync, iCUE, or any other tool has the USB device open, Hypercolor’s USB driver will not be able to connect to it. This is a kernel-level exclusion: only one process can hold a HID device at a time. If a device appears in lsusb but not in hypercolor devices list, check whether another RGB tool is running and holding it.

# Check which process holds your Razer device (adjust VID:PID as needed)
lsof /dev/hidraw* 2>/dev/null | grep -i razer

See conflicting software for the full list of known conflicts and how to resolve them.

#Checking your specific device

The fastest path:

# List devices Hypercolor has detected
hypercolor devices list

# Run discovery manually (useful for network devices)
hypercolor devices discover

# Full health and device report
hypercolor diagnose

If a USB device is missing, confirm udev rules are installed (just udev-install on a source build, or check your package’s post-install instructions), then re-plug the device. Network devices that are not discovered usually need their LAN control enabled in their companion app before mDNS broadcasting starts.

For a step-by-step device setup walkthrough, see finding devices.