Support for NZXT Kraken Z63 and Z73 #79
Comments
jonasmalacofilho
changed the title
|
Hi! New here, heard about your work from CaseySJ’s remarkable (and popular) Z390 hackintosh build guide over at tonymacx86. I don’t have the Z63 yet but it will arrive next week and I’m going to be interested in getting some sort of control over it within OSX 10.15. The build will also boot Win10 where I expect to simply use CAM. I’m not much of a coder myself, but just want to throw my hat in the ring here as someone interested in supporting the Z63. Please let me know how I can help! Thanks! |
|
Hi @jonasmalacofilho i have a z63 and running Linux. How can I grab what I do is required for supporting new device? |
|
Hi @astowe1080 and @inglor, Thank you both for expressing interest in helping out here. @inglor, can you start by running Afterwards, @astowe1080 and @inglor, we need some USB traffic captures. First I would like to ask you to disable as most dynamic features as possible (use a static animation, fixed pump and fan speeds, etc.), to reduce the amount of noise in the captured traffic. To capture USB traffic I recommend Wireshark, and you can post the pcap files here or add them to liquidctl-device-data. We would need to start with captures that show:
Later:
I would also like to ask you to describe how these are configured in CAM, and how they work on the cooler (since these are substantially new/different devices). Some screenshots can also help. For example: showing the temperature and rpms for the corresponding traffic captures. ¹ One way of supporting features based on CPU/GPU temperature is to send that value to the cooler, and let it handle after that. This is not how previous Krakens worked, but since the Z63/Z73 have the temperature display mode, it would make sense to use the embedded processor to handle that instead of relying on the main CPU to render new GIFs every second. TL;DR: there's a chance that the protocol supports something like this, which would be interesting. |
|
Hi @jonasmalacofilho see below for |
|
Thank you, @inglor. Can you confirm the firmware version of your Z63, as reported by CAM? It seems that this device simultaneously uses two interfaces, so when filtering captures it's important to use something like: (in this example: device is on bus 1, address 3, but we match all interfaces) I'm guessing that the bulk endpoint 2 on interface 0 is used to transfer the GIFs, while the hid/interrupt endpoints on interface 1 are used for status reporting and configuring cooling settings. |
Not really CAM software is so buggy that it doesn't work. I'm hit by the infamous "white screen" issue. I'm trying to resolve it with NZXT support but it's gonna take some time. Also I'm away for some days so I'll report back after back. Hopefully they would have released a new version of NZXT CAM as the 4.2.3 is buggy. |
Effective anti-analysis technique 🙂 |
|
Received mine, build looking good but I’m also out of town for a few days so I will install OS’s next week.
Maybe dumb question, but are the command line tools used for inspecting the Z63 USB traffic useful regardless of OS? In theory we’re trying to figure out how non-Windows OS’s interact with the Z63 but can Windows be used to gather the useful USB data? Or is the whole point needing to see the USB data from within Linux/OSX?
Thanks!
…Sent from my iPhone
On Feb 13, 2020, at 2:14 PM, Jonas Malaco ***@***.***> wrote:
Not really CAM software is so buggy that it doesn't work.
Effective anti-analysis technique 🙂
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Which tools do you mean?
Actually, we want to know how the software and/or kernel drivers supplied by manufacturer (usually only for Windows) interact with the device, so we can figure out how the protocol works and add support for it in our own cross-platform tool, liquidctl. Without suitable software or kernel drivers, there is not much interaction with the device (or any USB device, really). While the HID interface is standard (so Linux and macOS will bind a standard HID driver to it), it's not a mouse or keyboard and (AFAIK) the kernel won't automatically start to poll the device for reports. And no (practical) data will be sent to the device (other than very low level USB management stuff). |
|
Yep, was a dumb question 😅
I just meant lsusb and Wireshark. You definitely answered my question, Windows/CAM makes sense as starting point to pick apart NZXT’s drivers.
Fwiw, I got CAM v4.2.3 installed last night and it reported my Z63’s firmware as “5.0” — can dig in deeper with it next week.
… On Feb 14, 2020, at 3:37 AM, Jonas Malaco ***@***.***> wrote:
@astowe1080
command line tools used for inspecting the Z63 USB traffic
Which tools do you mean?
In theory we’re trying to figure out how non-Windows OS’s interact with the Z63 but can Windows be used to gather the useful USB data?
Actually, we want to know how the software and/or kernel drivers supplied by manufacturer (usually only for Windows) interact with the device, so we can figure out how the protocol works and add support for it in our own cross-platform tool, liquidctl.
Without suitable software or kernel drivers, there is not much interaction with the device (or any USB device, really). While the HID interface is standard (so Linux and macOS will bind a standard HID driver to it), it's not a mouse or keyboard and (AFAIK) the kernel won't automatically start to poll the device for reports. And no (practical) data will be sent to the device (other than very low level USB management stuff).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Don't worry about it : )
Thanks! |
|
Hi @jonasmalacofilho
Personally I'm a little disapointed as I was hoping to be able to monitor water temperature instead of CPU for spinning up pump and fans of the AIO. |
|
Thank you. I'll take a look as soon as I can. |
|
I’ve got Windows and OS X squared away now, looks like OS X can detect a couple things at surface level. Just in case you see something helpful in it, attached a screen grab from System Information within OS X.
I’ll give Wireshark a shot later today too —
Thanks!
… On Mar 1, 2020, at 4:11 AM, Jonas Malaco ***@***.***> wrote:
@inglor <https://github.com/inglor>
Thank you. I'll take a look as soon as I can.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#79>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQEUBW2DSSCSHF6O4KJ7Y3RFJGGBANCNFSM4KM5WUDQ>.
|
|
@astowe1080 the screenshot is missing. AFAIK all attachments are scrubbed when you reply to a issue directly from the email notification. |
|
I use the NZXT Z63 (CPU: Ryzen 3900x) with Arch Linux and Windows 10. It only shows me the liquid temperature. As I use Linux most of the time, I really would appreciate support for this version. |
|
@jonasmalacofilho
|
|
Thanks, I'll take a look as soon as I can. |
|
Z3 devices has 2 Endpoints. And looks like # 1 used for control/status and # 2 for upload LCD images. I guess that CAM software render and upload LCD images on demand. Hardware can store several images and then software can reuse old images by switching it via endpoint # 1 |
|
How is this progressing? Do the Z devices get any similarities with the latest generation X ones and would it help the PR#100 once merged? In terms of CAM software they released a new version which seems a new UI is in a place so maybe something changed under the hood as well (communication with the pump). Let me know if I can assist anyhow with trying to reverse engineer the API. |
|
Hi @inglor, It looks like the pump speed is set the same way between your Z63 and a X63. And the fan speed follows a very obvious/similar pattern. I haven't checked incoming status messages, but they also seem similar. So, as expected, the #100 should kick start the X63/X73 driver quite nicely.
A new UI yet again? Because CAM 3.x never got to support the new coolers, right? Well, thanks for letting me know. But if there are changes in the protocol, I expect them to be restricted to the LCD; or at most they could explain the differences we're seeing between the actual HUE 2 and the X63. Anyway, I'll keep this in mind and if necessary I'll ask you for a few additional captures. |
I tried @tomaculum's
Yeah I assume they upgrade it to add more support for the LCD screen. |
|
I just branched off a Z driver from the in-progress X one. Can you try This is unrelated to liquidctl, but it's now the second time a see a weird product description in lsusb. I'm thinking there might be a bug with a particular hub and/or in udev. Can you show me the |
|
I think I might have an answer for that. The Kraken Z series have an incompatibility list published recently from NZXT (see support post) with some motherboards and unfortunately mine is listed these. The "official" workaround is to get an internal USB hub for the motherboard. I think that's why it's appearing as this. Personally if I was given an option to RMA I'd choose it and maybe even go back to X series - disappointed with the issues I've had so far. For full I checked the branch as suggested and now it's appearing normally: But |
A non-compliant device and/or root hub (not sure what's causing the incompatibility) could explain what triggers the issue, but I still think this is showing that there's a buffer reuse bug in udev (or in lsusb and I missed that). Can you let me know what versions of libudev, systemd and lsusb you have? I would like to take a second look at this once I have some free time.
Were you running with root privileges? Or, alternatively, have you set up a udev rule that grants your user access to the hidraw device? Anyway, I messed up and that particular commit is useless: I never made KrakenZ3Driver a subclass of KrakenX3Driver, so right now it's just an abstract driver that will raise
|
That's what I did but wasn't able to get it fully working with the OLED screen.. What i did was a USB passthrough for the Kraken but apparently isn't enough for it's windows software to fully work. It apparently needs to see the CPU itself to read the temperatures and the load.. so the end effect was that NZXT cam pushed the animation to the OLED screen but it was suck at 0/0 values for example.. So I'm curious, were you able to overcome this problem as well? My VM is configured for CPU passthrough, so it sees all the cores, but couldn't make it to see it natively as host does. Is it possible somehow? If so this would also solve problem for NZXT cam within VM.. somebody? Appreciate your comments. |
Oh, I didn't. I think the packet is sent through usb interrupt. Does anyone have some interests working on this so we can talk about this in chat groups like gitter? I have several ideas but need more people to work on that. |
That's probably not going to work. Even if possible, it would mean giving the VM (probably unrestricted) access to the CPU MSRs, which could allow the Windows VM to do stuff the host doesn't expect.
You're welcome to join our developer's Discord server: https://discord.gg/Cyb5CFAhd9. |
|
Hi little bit of info about lcd...
And then u just tell device which image to show... (at least what i saw so far) Anyway I'll come back when I'll have more, seya. |
Ya, we already investigated LCD bucket, LCD mode, gifsicle, brightness, usb packets in discord but another guy showed full reverse engineering so we are pretty much stopped and waiting for him to post things now. |
Yeah, i just wanted to get rid of the CAM as soon as possible... but now when i know how they do things... and when i look at my $$$ Kraken... Im amazed... not even surprised why not even after a year so there is no fix (5m tops) for two GPUs and so and so... lol |
This comment has been minimized.
This comment has been minimized.
|
One interesting thing I've found with my new Z73 is that the default white mode (as on cold boot) shows, and updates, the liquid temperature properly. However, if I load a Windows VM, and pass the USB device through, and set it to display liquid temps via CAM, it no longer updates the liquid temp after closing the VM. I suppose this means that all the modes you can set via CAM are really just animated GIFs created by the software, and not programmed into firmware. I guess that makes sense, but still seems a little odd. The AIO obviously knows the liquid temp, so it must communicate that temp to CAM, which generates the GIF, then sends it back to the AIO. I would have expected that mode to be self contained. At any rate, I just thought that was an interesting tidbit of info. Is there any progress toward supporting the OLED? Is there any way I can help? I'm a developer myself, so I have some skills. ;) |
There hasn't been much progress besides what you can read in this issue. But please join our developer's Discord server: https://discord.gg/Cyb5CFAhd9. |
|
:( |
|
|
|
Thanks. :) |
|
@kebbleytea2 could you share your docker container? Maybe upload it to CA? |
Just a side-note, the docker stuff is unrelated to the issue, but anyway... I've got it as a public repo here: https://github.com/KebbleyTea/docker-liquidctl It currently requires escalated privileges, not really had the time to improve on that. But feel free to fork and improve. Hopefully that can get you started with it, in a container at least. I'm no expert. |
|
Since there was no status update on this in a while could anyone here maybe quickly confirm that it's at least possible to launch VirtualBox with Windows, pass the USB device through and permanently configure a gif? |
|
Yes. We also made some progress on protocol analysing in the discord server. So basically need somebody to implement the code and test it. |
|
@himekifee If it is of any help, I have a Z73 and I'd be more than happy to assist with testing code and/or capturing any data you may need, I'd love to get the LCD working with Manjaro. |
We've done 90% of the work in discord server. If you would like to help, please join discord server to help testing. Thanks. |
|
Add Z53 to this list. I can test that model if this gets implemented. |
|
I'm still looking at creating a Cam like front end for this, just waiting for support to come to liquidctl. I'm not a Python guy, so I can't be of much help with the actual implementation. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Is there some example code somewhere for the gif transfer? |
|
We do have almost complete reverse-engineered protocol just no one is doing programming rn. You may also check KrakenZPlayground for some gif transfer code. |
|
I am using z73 on a x299 hackintosh and like to help if needed. The windows in parallels cannot see the usb device. |
|
Replaced by #444, as this was getting quite long despite being stalled and not containing that much technical information. |
jonasmalacofilho
added
the
unresolved/archived
and others
Status: monitoring, fan/pump speeds and profiles and HUE 2 are already supported in the main branch. The main thing left to do is add support for the screen.
The new Kraken Z series adds an LCD to the pump/block top.
https://www.nzxt.com/products/kraken-z63
https://www.nzxt.com/products/kraken-z73
While these certainly require a new protocol to handle the LCD graphics, it might end up being an extension to (or part of) the (presumably) already new protocol for the X63/X73 (see #78).
I'm not sure if there will be a lot of interest in these devices (based on pricing and adoption of the existing competitors), much less of using them on platforms other than Windows or with software other than CAM.
Still, please add a 👍 if you are interested in support for either of these devices in liquidctl.
Additionally, if you have one of these, please get in touch (a comment is fine, but you can also reach me by email) so we can talk about working together on a driver.
Status:
Assorted notes:
The text was updated successfully, but these errors were encountered: