And that something triggered the reply that arrived in 000004. If you look at transfer 000003 it looks as if no data bytes were sent, but 'something' was sent.I did not encounter this issue when working on the Smart Device V2. Zsh: terminated liquidctl -product 0x5702 initialize -debug -d 0 _rgb_fusion: Command written, waiting for reply _rgb_fusion: write cc 60 (and 62 padding bytes) liquidctl.cli: device: Gigabyte RGB Fusion 2.0 (experimental) liquidctl.cli: mixing -device with other filters is not recommended to disambiguate between results prefer -pick : probing drivers for device 0xbda:0x411 : probing drivers for device 0xbda:0x5411 : probing drivers for device 0x46d:0x82d : instanced driver for Gigabyte RGB Fusion 2.0 (experimental) : probing drivers for device 0x48d:0x5702 : probing drivers for device 0x46d:0xc52b : searching GenericHidBus (api=hid, drivers=) liquidctl.cli: running liquidctl v1.3.3 (homebrew liquidctl 1.3.3) We can see this here (the last line is after killing the driver % liquidctl -product 0x5702 initialize -debug -d 0 Unfortunately - and I'm doing all of this on macOS - when I issue the command followed by data=self._read(), the command never returns. W.Īll of this is well and good, so what's the problem? Byte 4 ( 0x07) may represent the number of lighting channels (in fact there are 7) and the next 4 bytes ( 0x01, 0x00, 0x0A, 0x00) represent the full version number 1.0.10.0 which is also present at the end of the string GIGABYTE V1.0.10.0.Ġ00003: Class-Specific Request (DOWN), 22:12:25.1783814 +0.0000156 (1. And the result certainly contains initialization information. In the continuation below we now see **Get** 0x40 bytes from the device.

Gigabyte rgb fusion not installing