Add experimental partial support for ASUS ROG RYUJIN II 360

[FlorianFreudiger]

Hello, I implemented a driver for the ASUS ROG RYUJIN II 360 liquid cooler.
While there is a screen, I only implemented control and status requests of the pump, the embedded fan and the attached fan controller.

Since I only own the 360mm variant I don't know how similar the first and third generations and the different sizes are to one another, so I was a bit confused on what I should name the driver, documentation, etc.

I also noticed that requesting device status does sometimes time out, maybe I am missing something

Fixes:
Closes:
Related:

---

Checklist:

• Adhere to the development process
• Conform to the style guide
• Verify that the changes work as expected on real hardware
• Add automated tests cases
• Verify that all (other) automated tests (still) pass
• Update/add documentation
  • README, with "new/changed in" notes
  • applicable docs/*guide.md device guides, with "new/changed in" notes
  • liquidctl.8 Linux/Unix/Mac OS man page
  • protocol documentation in docs/developer/protocol
• Submit relevant data, scripts or dissectors to https://github.com/liquidctl/collected-device-data

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 (at least e) and git MRLV

New driver?

• Document the protocol in docs/developer/protocol/

[aleksamagicka]

Thanks for the PR! Some comments enclosed.

I also noticed that requesting device status does sometimes time out, maybe I am missing something

Did you try without the official software running? Often the official software will meddle with or outright prevent liquidctl and others from accessing the device(s).

[FlorianFreudiger]

Did you try without the official software running? Often the official software will meddle with or outright prevent liquidctl and others from accessing the device(s).

Interestingly, I experience the opposite, the timeouts only occur sometimes when dual-booting to a Linux system that does not have any official software installed.
When the official software is or was running on a Windows system, I didn't experience any timeout (yet).

Maybe I am missing some initialization?

[aleksamagicka]

Maybe I am missing some initialization?

That's possible, I seem to recall a device that needs an init, otherwise results could be inconsistent. (Can't remember the exact name.)

Look up what the official software sends once it loads.

[FlorianFreudiger]

Turns out the timeouts were caused by clear_enqueued_reports() being called after write() but before read()...
Moving clear_enqueued_reports() to before write() calls fixed this issue

[aleksamagicka]

Right, should have noticed it earlier. That's also how the NZXT Kraken Z driver code does it, since those also require a command to get back status. Clearing before a read is fine if the device is sending status on its own, like Aquacomputer usually does.

[aleksamagicka]

(Side note, looks like Github doesn't send an email when the PR is marked as ready for review? Would have looked earlier if it did.)

[FlorianFreudiger]

(Side note, looks like Github doesn't send an email when the PR is marked as ready for review? Would have looked earlier if it did.)

No worries, apparently GitHub only sends such updates to assigned reviewers

[aleksamagicka]

No worries, apparently GitHub only sends such updates to assigned reviewers

TIL. Github logic, I guess. Feel free to ping if ever needed in that case.

I think this LGTM. Are you on Linux by chance? I think I can whip up a kernel driver for this.

---

@jonasmalacofilho, can you please look over?

[FlorianFreudiger]

Are you on Linux by chance? I think I can whip up a kernel driver for this.

I am dual-booting both Windows and Linux, I tested the driver on both systems. I can help with testing a kernel driver

[aleksamagicka]

Thanks. Well, here it is, you just need to run make dev after cloning (it will generate harmless output) and it should show up in sensors (lm-sensors package, usually). Instructions for setting fan speeds are in the README.

Hopefully I got most of it right! Please report if something is off or doesn't work.

Also, quick question: how does the fan controller connect to the AIO?

[FlorianFreudiger]

Thanks. Well, here it is

Well, that was quick! Will test it later today or tomorrow!

Also, quick question: how does the fan controller connect to the AIO?

The cooling block is connected to the fan controller via USB micro-B cable (plugging into the controller).
See cabling on pages 17-19 in the quick start guide.

I believe this cable also powers the pump, meaning you cannot use the cooler without the fan controller.

[FlorianFreudiger]

Apparently the Ryujin II is the only generation that uses this weird fan controller combo, both Ryujin (I) and Ryujin III don't have it included, connecting directly to the motherboard instead.

---

As a side note, I also found an open issue on OpenRGB for the Ryujin (I), containing some protocol data.
The headers seem to be a bit different but I think if implemented in the future it probably makes sense to keep them both in the same driver.

OpenRGB supports liquid coolers of the ASUS Ryuo family which at a quick glance seem to also have similar protocols (excerpt status function). Also concerns #560.

[jonasmalacofilho]

The implementation looks very good to me. But I think we can improve the names and the output of the various fan channels.

I also have some nitpicks on how we should name the device and filenames, mostly related to ASUS marketing noise, but also for consistency with our other ASUS drivers.

[jonasmalacofilho]

You can ignore the unrelated second failure on tests/test_kraken3.py::test_krakenz3_not_totally_broken (related: #661).

The first failure is due to tests/test_asus_ryujin.py::test_status needing to be updated after the driver changes.

[jonasmalacofilho]

Merging, thanks!