Add support for setting fan speed for D5 Next#499
Add support for setting fan speed for D5 Next#499jonasmalacofilho merged 33 commits intoliquidctl:mainfrom
Conversation
|
Sorry again for the delay.
Yes, and it should actually be preferred (when there's a hwmon driver).
That's mostly just because hwmon support in liquidctl is new and not yet complete, but also because not all current hwmon drivers expose PWM control (e.g. Kraken X2, because of device/protocol issues, or Corsair RMi/HXi, due to safety concerns, IIRC).
No, I think it should be the other way around, just as with Besides being more consistent, this minimizes the chances of putting either the device or the kernel driver in a inconsistent/unexpected state. |
|
Great, thanks. I'll rework it to use hwmon first, if possible. |
87852f1 to
15edba3
Compare
…) and hwmon access
|
Writing to hwmon is now implemented in the aquacomputer driver, please take a look. |
docs/aquacomputer-d5next-guide.md
Outdated
| Valid channel values on the D5 Next are `pump` and `fan`. The hwmon driver is always used first, if it's available and | ||
| exposes `pwmX` and `pwmX_enable` attributes. You can pass in `--direct-access` to bypass it and communicate with the | ||
| device directly. |
There was a problem hiding this comment.
I don't think it's necessary to talk about hwmon here, especially since the very next section is about it (and how to bypass it).
liquidctl.8
Outdated
| .SS Aquacomputer Octo | ||
| .SS Aquacomputer Quadro | ||
| Cooling channels: (D5 Next, Octo, Quadro:) not yet supported; (Farbwerk 360:) not applicable. | ||
| Cooling channels: (D5 Next): supported, (Octo, Quadro:) not yet supported; (Farbwerk 360:) not applicable. |
There was a problem hiding this comment.
| Cooling channels: (D5 Next): supported, (Octo, Quadro:) not yet supported; (Farbwerk 360:) not applicable. | |
| Cooling channels: (D5 Next): \fIfan\fR, \fIpump\fR; (Octo, Quadro:) not yet supported; (Farbwerk 360:) not applicable. |
liquidctl/driver/aquacomputer.py
Outdated
| _LOGGER.info( | ||
| "bound to %s kernel driver, writing fixed speed to hwmon", self._hwmon.driver | ||
| ) | ||
| return self._set_fixed_speed_hwmon(channel, duty) |
There was a problem hiding this comment.
This will fail if the hwmon driver is present, but doesn't expose the necessary PWM attributes.
I think we should instead automatically fallback to direct access in that case.
liquidctl/driver/aquacomputer.py
Outdated
| _LOGGER.warning( | ||
| "directly writing fixed speed despite %s kernel driver", self._hwmon.driver | ||
| ) |
There was a problem hiding this comment.
Related to the previous comment, in my opinion a warning is only necessary if we're re-implementing (and possibly conflicting with) something the kernel driver actually supports/exposes.
liquidctl/driver/hwmon.py
Outdated
| def write_str(self, name, value): | ||
| (self.path / name).write_text(value) |
There was a problem hiding this comment.
For symmetry, I think a write_int API would be better, and move the str() conversion within it.
On a related note, it would also probably make sense to rename get_int to read_int, also for symmetry.
There was a problem hiding this comment.
Since renaming get_int to read_int touches more drivers than aquacomputer.py, do you want me to create a separate PR right after this one or do it here?
There was a problem hiding this comment.
You're right, that would be better.
tests/test_aquacomputer.py
Outdated
| def test_d5next_set_fixed_speeds_not_supported(mockD5NextDevice): | ||
| with pytest.raises(NotSupportedByDriver): | ||
| mockD5NextDevice.set_fixed_speed("fan", 42) | ||
| def test_d5next_set_fixed_speeds_directly(mockD5NextDevice): |
There was a problem hiding this comment.
Similarly to test_d5next_get_status_directly, this should also test whether --direct-access is honored, even if a (complete) hwmon driver is present.
But I do see how this might be getting a bit repetitive/annoying.
tests/test_aquacomputer.py
Outdated
| assert pump_report.data[0x95:0x98] == [0, 32, 208] # 0, <8400> | ||
|
|
||
|
|
||
| def test_d5next_set_fixed_speeds_hwmon(mockD5NextDevice, tmp_path): |
There was a problem hiding this comment.
It might be wise to also test whether the fallback to direct mode when the PWM attributes are missing.
|
Since crcmod is stable but not actively maintained, let's exceptionally pin its required version to 1.7. I usually don't do this type of thing in order to avoid issues with distro-supplied packages. But in this case we really don't expect to see a new version, and I'm not super comfortable leaving a highly popular but potentially1 neglected dependency unpinned. Footnotes
|
…ct access if they aren't
|
Thanks for the review, things you mentioned should be fixed now, except the |
|
Thanks! |
Add support for setting pump and fan speed for the D5 Next pump in the
aquacomputer.pydriver.I had to use the
crcmodlibrary to calculate CRC-16/USB checksums, because the control HID report (that contains all the settings for a device) has one at the end and it needs to be updated when the settings are changed. Please let me know if I missed adding it somewhere.Also I wanted to ask if it's OK to utilize the hwmon driver for writing stuff to the device. I don't really see than being done in other drivers, so maybe
--use-hwmoncan be passed in here to let the user go through the kernel driver?Related: #439
Checklist:
liquidctl.8Linux/Unix/Mac OS man pagedocs/*guide.mddevice guidesNew CLI flag?
extra/completions/New device?
extra/linux/71-liquidctl.rules(instructions in the file header)en)New driver?
docs/developer/protocol/