liquidctl / liquidtux Goto Github PK

View Code? Open in Web Editor NEW

75.0 11.0 14.0 172 KB

Linux kernel hwmon drivers for AIO liquid coolers and other devices

License: Other

Makefile 1.62% C 97.76% Shell 0.62%

linux hwmon nzxt

liquidtux's Introduction

liquidtux

Linux kernel hwmon drivers for AIO liquid coolers and other devices

The goal of this project is to offer hardware monitoring drivers for closed-loop liquid coolers and other devices supported by liquidctl, making their sensor data available in /sys/class/hwmon/hwmon*.

By using the standard hwmon sysfs interface, sensors, tools using libsensors, as well as programs that read directly from the raw sysfs interface can access these devices' sensors. For more information, read the documentation of the hwmon sysfs interface and check the lm-sensors repository.

Device support

As the drivers mature, they will be proposed to, and hopefully reach, the mainline kernel.

This is the current state of the drivers in regards to this process:

Device	Driver name	hwmon name	Upstream
NZXT Grid+ V3/Smart Device (V1)	`nzxt-grid3`	`smartdevice`	getting ready to submit
NZXT Kraken X42/X52/X62/X72	`nzxt-kraken2`	`kraken2`	in Linux 5.13 (patch)
NZXT Kraken X53/X63/X73, Z53/Z63/Z73, Kraken 2023 (standard, Elite)	`nzxt-kraken3`	`kraken3`	in Linux 6.9 (patch), Kraken 2023 - in Linux 6.10 (patch)
NZXT Smart Device V2/RGB & Fan Controller	`nzxt-smart2`	`nzxtsmart2`	in Linux 5.17 (patch)

This repository contains the latest state of each driver, including features and bug fixes that are not yet submitted upstream.

Note: other hwmon drivers exist in the mainline kernel for devices that liquidctl also supports: corsair-cpro, corsair-psu.

Installing with DKMS

ArchLinux users can try the liquidtux-dkms-git^AUR package. After the package is installed, manually load the desired drivers.

$ sudo modprobe nzxt-grid3              # NZXT Grid+ V3/Smart Device (V1)
$ sudo modprobe nzxt-kraken2            # NZXT Kraken X42/X52/X62/X72
$ sudo modprobe nzxt-kraken3            # NZXT Kraken X53/X63/X73, Z53/Z63/Z73, Kraken 2023 (standard, Elite)
$ sudo modprobe nzxt-smart2             # NZXT Smart Device V2/RGB & Fan Controller

Those on other distros can install DKMS files using dkms_install Makefile target:

$ sudo make dkms_install

Then build and install the modules using:

$ sudo dkms install -m liquidtux -v $(./gitversion.sh)

Also, dkms_install supports DESTDIR variable, so it could be used for building distribution-specific packages.

Manually building, inserting and installing

The drivers should be built with the kbuild system.

A simple Makefile is provided that simplifies this in normal scenarios. The built modules can then be loaded with insmod.

$ make
$ sudo insmod drivers/hwmon/nzxt-grid3.ko         # NZXT Grid+ V3/Smart Device (V1)
$ sudo insmod drivers/hwmon/nzxt-kraken2.ko       # NZXT Kraken X42/X52/X62/X72
$ sudo insmod drivers/hwmon/nzxt-kraken3.ko       # NZXT Kraken X53/X63/X73, Z53/Z63/Z73, Kraken 2023 (standard, Elite)
$ sudo insmod drivers/hwmon/nzxt-smart2.ko        # NZXT Smart Device V2/RGB & Fan Controller

To unload them, use rmmod or modprobe -r.

If testing was successful the modules can be installed to the system with the modules_install target:

$ sudo make modules_install

liquidtux's People

Contributors

Stargazers

Watchers

Forkers

khoonirobo mstrthealias grmat inglor minego amezin stalkerg lmoe murodin happy-ferret aleksamagicka jonasmalacofilho demibsel ariche2

liquidtux's Issues

nzxt-smart2: maybe error on stale data?

#34 (comment)

Other drivers return ENODATA when the last report is too old. Maybe I should do the same in nzxt-smart2.

Disable squash merges

I want to keep the driver in liquidtux repo up to date with changes in the kernel tree.

This means I should import changes contributed by other people into liquidtux.

And, in turn, this means pull requests should not be squashed - to keep track of already imported patches, and to keep original authors.

Could we agree on disabling squash merge in the repository?

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests

Match file locations with the kernel tree

Could we move files in the repository to the same location as in the kernel repository?

I. e.:

drivers/hwmon/nzxt-*.c
Documentation/hwmon/nzxt-*.rst

It should make it much easier to move patches between this repository and the kernel

Building with W=1?

Just found a very interesting discussion starting here, related to the warnings that the 0-day bot finds and how to find them before sending the patch upstream.

Guenter then summed up his requirements. We already have checkpatch CI here, so adding W=1 seems like a good thing to add as well.

Thoughts? Maybe also add C=1 (that invokes sparse)?

NZXT Smartdevice v2 support

Is anyone currently working on this?

I started some work. But it's very ugly cargo cult coding. And based on the now quite refactored nzxt-smartdevice.c driver.

ci: test CONFIG_DEBUG_FS=y/n

nzxt-kraken3.c contains #ifdef CONFIG_DEBUG_FS

Grid v3 upstreaming

We have two almost complete drivers for grid v3, and none upstreamed. That's not good.

@jonasmalacofilho Could you explain what's missing/wrong with nzxt-grid3.c in this repository?

And I'll try to recall the state of my implementation...

gitversion.sh (and then dkms) fails on clones without tags

Clone with only master branch (no tags): https://github.com/aleksamagicka/liquidtux/actions/runs/4240522240/jobs/7369631715

fatal: No names found, cannot describe anything.

Possible solutions:

git describe --always (only commit hash when tag not found)
Fallback value (hardcoded v0.1.0 when git describe fails)

ci: enable codespell

f2dd20e

According to the docs checkpatch has --codespell flag, which should catch typos like this.

Interest for EVGA and Corsair coolers using 5th gen. Asetek designs

I'm opening this issue to track the interest for (and later work on) a driver that supports:

2433:b200 EVGA CLC 120 (CL12), 240, 280, 360, a.k.a. Asetek 690LC
1b1c:0c0[8,9,a] Corsair H80i v2, H100i v2, H115i
1b1c:0c0[2,3,7] Corsair H80i GT, H100i GTX, H110i GTX

For now, please comment with the specific device you have, its lsusb -v output, what tools you already use to control it, and how would you be able to help to develop, test and maintain this driver.

The driver will need to be able to differentiate between the modern and legacy variants of the generic 2433:b200 Asetek 690LC.

Support for the legacy variants (e.g. Kraken X61) will be very hard to include, if not impossible, as those devices don't allow parameters to be independently read or changed.

Kernel driver for corsair coolers

I re-uploaded a kernel driver someone wrote for corsair coolers here which may make sense to merge into this project if you're interested in supporting corsair devices. I was looking for something to support my corsair cooler that would be suitable for upstreaming to the mainline Linux kernel.

nzxt-kraken: Incorrect order of failing in probe

Both nzxt-kraken drivers share similar _probe() code with the same mistake of calling hid_hw_stop() and hid_hw_close() even if their _start() and _open() counterparts returned an error.

(Discovered on LKML by reusing the code for the gigabyte_waterforce driver.)

nzxt-kraken3 upstreaming?

Since liquidctl is currently frozen for new PRs, I've been looking over drivers in this repo, and currently nzxt-kraken3 caught my eye. It's simple and looking at the liquidctl driver for it, the second ID for X53 and similar should be added.

I'd like to help to get it upstreamed (I'll gladly submit patches to LKML if needed), and then later Z53/..., PWM or PWM/temp curve support can possibly be added (from #7), IMO it's better that it's out there in the kernel than only being here. If that's OK I'd proceed in buying a non-RGB X53 for testing the driver and changes.

Thanks

Just wanted to say that this works fine with my Kraken X42 on Linux 5.9.8.

Thanks for your work!

X63 support

I'd like to be able to access the liquid temperature reported by my Kraken X63, so I can see it with the sensors command and use it as an input for fancontrol.

Usage with fancontrol

I tried out this mod with Manjaro and it works great, getting the liquid temp and fan speeds showing up in sensors. However when I try to configure fancontrol (manually) it will not work as it thinks it’s a PWM fan. I can post more detailed config and error messages later.

In the meantime, any suggestions for how to make fancontrol control the X52 (in my case)?

Thanks,
Max

nzxt-kraken2: fan/pump control

I do not have the device, I've just read the commit message torvalds/linux@82e3430.

Fan and pump control, while supported by the devices, are not currently
exposed. The firmware accepts up to 61 trip points per channel
(fan/pump), but the same set of trip temperatures has to be maintained
for both; with pwmX_auto_point_Y_temp attributes, users would need to
maintain this invariant themselves.

pwm controls don't have to match fan channels. You could expose just one pwm channel that controls both the pump and the fan. pwmconfig should accept this as far as I understand: it tries to detect which fan is controlled by which pwm, so it will probably pick either fan or pump randomly.

nzxt-kraken3.c: ‘get_fw_version_cmd’ defined but not used with CONFIG_DEBUG_FS=n

With CONFIG_DEBUG_FS disabled:

/home/runner/work/liquidtux/liquidtux/src/nzxt-kraken3.c:60:11: error: ‘get_fw_version_cmd’ defined but not used [-Werror=unused-variable]

https://github.com/liquidctl/liquidtux/actions/runs/4236845621/jobs/7362126983

Migrate to Rust

Why?

It is just for a discussion.
Educate how kernel Rust is working.
liquidtux is small enough to create such a migration without too much effort.
We already have some race condition challenges maybe Rust can simplify them.
Just-for-fun, hype

It's not a proposal I just want to hear your opinion. For me the main obstacle it's the lack of GCC support (yet) and in that case, we must build kernel by llvm.

Regards,