Create a device driver

[jaksi]

The current solution does not keep its state, nor does support continuous monitoring and fan profiles.

A Linux device driver should be created, exposing the the liquid temperature, the fan/pump speed and the color mode.

[robfrawley]

@jaksi What is your workflow like? Do you plan on creating a x-dev branch with active work? I ask b/c I may have some free time in the coming weeks and this is near the top of my to-contribute-to list. That said, I don't want to duplicate anything you may have locally not pushed.

[jaksi]

@robfrawley It's really sporadic, but I always try to push my work upstream and keep local changes at a minimum. There isn't any work done for this issue either.

I plan to use the feature branch workflow (separate branches for issues), at least for larger tasks like this.

Generally, go ahead, if you don't see a branch for an issue, there's probably no work done on it.

[robfrawley]

@jaksi Cool beans; thanks for the info!

I was wondering if there was any progress made on this issue. I was also wondering if it mattered if this enhancement was a daemon or a device driver. I am willing to contribute I have some time on weekends.

[jaksi]

@RBlafford My original plan was to make a kernel driver as well, this Python proof of concept just ended up being good enough for me not to work on a device driver. That being said, I'm open to this approach.

Unfortunately I had to move to a new place last month, so I didn't work on this project at all.
Now that I actually have a working internet connection at my new place, I do want to continue working on it.

@jaksi Neat, I have been experimenting with the linux usb core and your findings for a little while, I currently have the skeleton of a driver. I'd like to collaborate if possible

[jaksi]

@RBlafford Of course, your help is much appreciated.

I've found a driver which is somewhat similar to what we need (a thermometer driver):
https://github.com/torvalds/linux/blob/master/drivers/usb/misc/cytherm.c
It exposes the readings of a USB thermometer via sysfs entries, and also supports setting its brightness.
We'd need to expose the readings of the liquid temperature and the fan/pump speed, and support setting those speeds or a profile, and the color mode.

@jaksi yes this is great stuff. I've seen sample code very similar to this. Once this device driver is made then I guess we would need to make a user-space program that writes and reads to these sysfs entries too. This program could also hold state and configuration settings.

After some research, I have found that its probably unlikely that there is a command that will just read the status of the device. It is only possible to read that status of the device after a set of some type. This leads to me believe that a daemon, rather then a driver would make more sense for this product, which is probably why CAM is a daemon as well. We should probably close this issue and reopen the issue to make a levd daemon program, rather then a driver analogue.

Interesting aside, turns out that the hardware controlling this device is the same as another: Kuhler 920. Probing the internet turned up this source code here: https://sourceforge.net/projects/kuhlerdriver/. This is a C daemon and corresponding utility program that will issue commands to the Kuhler 920, i've tested it on the Kraken, and everything works as expected.

[jaksi]

@RBlafford I pushed an early version of a device driver on a branch:
https://github.com/jaksi/leviathan/tree/device_driver
It basically does everything the Python implementation does, but in a more elegant way (remembers settings, no need to pass every parameter just to change a single one).
The plan is to create a kernel timer that communicates with the device in a similar way to the CAM software (reads and writes data every second, responds to temperature changes by following a customizable fan curve).

[robfrawley]

@jaksi The new device driver works wonderfully on a Kraken X41; love it! Great job in implementing a first pass on the device driver.

[ARandomOWL]

@jaksi Will the device driver become the main focus of the project, making the Python script obsolete?