Skip to content

Add support for Gigabyte Aorus Waterforce X II 360 (Castor3)#870

Open
Bigginz87 wants to merge 1 commit into
liquidctl:mainfrom
Bigginz87:gigabyte-castor3
Open

Add support for Gigabyte Aorus Waterforce X II 360 (Castor3)#870
Bigginz87 wants to merge 1 commit into
liquidctl:mainfrom
Bigginz87:gigabyte-castor3

Conversation

@Bigginz87
Copy link
Copy Markdown

@Bigginz87 Bigginz87 commented Mar 11, 2026 •
edited
Loading

New driver for the Gigabyte Aorus Waterforce X II 360 AIO cooler, which uses the Castor3 controller (VID=0x0414, PID=0x7a5e).

Supported features:

  • Fan control: named presets, fixed speed, custom curves
  • Pump mode: balanced / turbo
  • LED ring: 12 lighting effects with palette support
  • LCD display: 5 Enthusiast modes, rotation, carousel
  • Custom image upload with auto-resize to 320x320
  • System info overlay and text overlay (Pango/Cairo)
  • ROM management: list, upload, delete
  • Background sensor push daemon for live display updates

Protocol fully reverse-engineered from USB packet captures of Gigabyte Control Center (GCC). All commands confirmed on hardware.

Linux only (hwmon sysfs + /proc/stat for sensor data).

Checklist:

New CLI flag?

  • Adjust the completion scripts in extra/completions/

New device?

  • Regenerate extra/linux/71-liquidctl.rules (instructions in the file header)
  • Add entry to the README's supported device list with applicable notes and git MRLV

New driver?

  • Document the protocol in docs/developer/protocol/

@Bigginz87
Add support for Gigabyte Aorus Waterforce X II 360 (Castor3)
3de4765 
New driver for the Gigabyte Aorus Waterforce X II 360 AIO cooler,
which uses the Castor3 controller (VID=0x0414, PID=0x7a5e).

Supported features:
- Fan control: named presets, fixed speed, custom curves
- Pump mode: balanced / turbo
- LED ring: 12 lighting effects with palette support
- LCD display: 5 Enthusiast modes, rotation, carousel
- Custom image upload with auto-resize to 320x320
- System info overlay and text overlay (Pango/Cairo)
- ROM management: list, upload, delete
- Background sensor push daemon for live display updates

Protocol fully reverse-engineered from USB packet captures of
Gigabyte Control Center (GCC). All commands confirmed on hardware.

Linux only (hwmon sysfs + /proc/stat for sensor data).
@mushusu
Copy link
Copy Markdown

mushusu commented Apr 11, 2026

Technical feedback for Aorus Waterforce X II 360 (Castor3 driver) on Linux

Environment:

  • OS: CachyOS (Kernel 6.x+)
  • Python version: 3.14
  • Hardware: Gigabyte Aorus Waterforce X II 360 (Firmware v2)
  • Driver branch: castor3 experimental

Observed Issues:

  1. API Regression: The function find_liquidctl_devices returns a generator instead of a list. This causes a TypeError: 'generator' object is not subscriptable in scripts expecting traditional list indexing.

  2. HID Session Lock (OSError): When calling initialize(), the driver immediately starts the sensor push daemon. Any subsequent call to set_screen (command 0xE7) or set_color fails with OSError: Could not write to device. It appears the telemetry loop saturates the HID bandwidth or the firmware fails to handle concurrent configuration packets.

    • Workaround used: Performing all configurations (set_screen and set_color) before calling initialize() or within a single persistent dev.connect() session.

  3. LED Persistence: The device resets its lighting state to the factory "Rainbow" effect upon starting the telemetry stream. The current implementation does not seem to re-apply or "keep-alive" the user-defined static colors once the sensor data starts flowing.

  4. Resource Cleanup (usbfs): The driver fails to release the HID interface upon process termination. The device remains bound to the usbfs driver, requiring a manual unbind/bind through sysfs or a usbreset to be visible again to hidapi.

Proposed Improvements:

  • Implement a small delay after initialize() before allowing further HID writes.

  • Ensure the lighting state is re-asserted after the telemetry session is established.

  • Modify the background daemon to properly release the device handle on exit/SIGTERM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Bigginz87 @mushusu