liquidctl / liquidtux Goto Github PK

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.

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.

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

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.)

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.

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)

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

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)?

Why?

1. It is just for a discussion.
2. Educate how kernel Rust is working.
3. liquidtux is small enough to create such a migration without too much effort.
4. We already have some race condition challenges maybe Rust can simplify them.
5. 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,

f2dd20e

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

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

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...

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

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.

#34 (comment)

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

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

Thanks for your work!

nzxt-kraken3.c contains #ifdef CONFIG_DEBUG_FS

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.

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.