Initial Razer Hanbo Chroma support
Initial commit for the Razer Hanbo Chroma AIO liquid cooler.
Proposed OpenRGB-Wiki Documentation
Features:
- Direct, Spectrum Cycle & Off modes.
- Zone support for pump cap and individual fans.
-
Hardware brightness support in direct mode.Possibly, if it can be made to behave with the Effects Plugin. - Firmware and serial number.
Limitations:
- Fans and pump are capable of using separate brightness parameters, but only one slider exists in the GUI so they are combined.
- Developed against the 360mm variant under Linux (Opensuse Tumbleweed / Linux 6.14) with firmware 1.2.0
To-do (proposed):
-
Check for compatibility with 240mm variant. -
Check for compatibility with older firmware. -
Check for compatibility outside of Linux. -
Prevent device black-out when initially entering direct mode. -
Interop testing with a busy interface e.g. effects plug-in running with liquidctl / hwmon. -
Check udev rules for deployment.
Implementation notes:
The Razer Hanbo protocol appears to be fundamentally different from any other Razer device resulting in its own detector & controller. The Razer Kraken implementation was consulted for structure and interaction with common Razer components.
Writing RGB updates to the AIO does not generate any sort of acknowledgement beyond changes in hardware. Testing on my sample indicated that sending updates too fast gives undesirable results. The USB read timeout of 2ms used for other transactions was found to be reliable for spacing out requests, this was the value chosen for sleeping after sending a RGB update. It was also noted that the OEM software issues RGB updates at 3-10ms intervals. Further interop testing will likely tweak this value in addition to other congestion mitigations.
A quirk of entering direct mode is that the AIO blacks out until a RGB update is sent to it. I'm not particularly fussed about this but I'm happy to take suggestions on how to force an update post-device load without GUI or profile interaction.
Sensor and speed profile support is under development through liquidtux for hwmon and liquidctl for a userland implementation.
Checklist for Accepting a Merge Request for a New Device
-
The source branch of the merge request is not protected ( masteris protected by default when creating a fork, so it is recommended to not use it as your source). -
The New Deviceissue raised for this device is linked to this MR with a keywordCloses / Resolves / Implements -
There is a device protocol page in the Developer Wiki or there is enough information / captures in the New Deviceissue to provide ongoing support. -
The code to be merged follows the style guide and change requirements as documented in the contributing guide.
-
Meta data for the device is included in RGBController_*file -
This device is detected and is working on Windows 10 and / or 11 -
This device is detected and is working on Linux (Please specify distribution and releases tested) -
Logging for Info, Warnings and Errors has been added for troubleshooting purposes