commit 1f76c5caef on 'master'.
The Smart Device V2 regularly sends both b'6702' and b'6704' prefixed
status messages, and the fan (speed) information is in the first one.
Commit 2538baec0b accidentally changed the code to wait for (and try
to parse as fan information) the incorrect message; this fixes it.
Fixes: 2538baec0b ("Move the reporting of SDV2 firmware and LED infos
to initialize")
Fixes: #71 ("Smart Device V2 fan status issue")
Reported-by: @CaseySJ
Suggested-by: @CaseySJ
The patch for PyUSB successfully prevents access violation errors during
cleanup with libusb 1.0.22, but "some libusb_devices were leaked"
warnings can still be seen with LIBUSB_DEBUG=3.
Patch: 8041ec11b2c4 ("Fix #203: libusb sometimes cleaned up too early.")
Related: pyusb/pyusb#227 ("Fix #203: libusb sometimes cleaned up too early.")
Related: pyusb/pyusb#203 ("OSError with wxPython #203")
For now a simple case-insensitive comparison is used, but this could
easily be extended to use some type of pattern matching.
A few short option aliases have also been added:
- `-m` for `--match`
- `-n` for `--pick`
Commit bf27bfb81b ("Mark old drivers that are stable as such") stated:
> NZXT Kraken X31, X41, X61: know to work *with limitations,* but no
> recent *bug* reports. The limitations are minor and allow for a very
> resilient driver, that should even work with other devices.
However since then an issue was opened that qualifies to me as
significant: #66 ("Kraken X61 pump makes grinding noises with
liquidctl/libusbK").
While I'm not sure that's really a bug, and the user doesn't seem
interested in providing any additional details, I think it's wise to
keep these devices marked as experimental for at least one more release.
Still regarding this issue:
- the user failed to notice that the recommended driver was WinUSB;
while that could absolutely be my fault, and I've since patched the
README to make it more clear, I'm not conviced the rest of the issue
isn't just about (following) the documentation
- we don't really know the legacy Krakens behave with the libusbK
driver, and it seems that the issue persisted reboots but went away
when the Asetek driver was restored, suggesting a possible connection
Related: #67 ("Keep track of --legacy-690lc")
liquidctl.cli.find_all_supported_devices was never intended to be part
of the public API. After all, it's in the cli.py module.
Regardless, it is used by other software, so document that it has been
deprecated in favor of liquidctl.driver.find_liquidctl_devices.
This is done in preparation to the upcoming v1.3.0 release, which
introduces support for many new devices.
Corsair H80i v2, H100i v2, H115i: known to work and no recent bug reports.
NZXT Kraken X31, X41, X61: know to work *with limitations,* but no
recent *bug* reports. The limitations are minor and allow for a very
resilient driver, that should even work with other devices.
NZXT Grid+ V3: already supported for almost a year, and there have been
no bug reports. Unfortunately, I don't remember seeing any confirmation
that it works, so I'm going mostly by how long it's been in liquidctl.
Unlike what the PyUSB FAQ suggests, get_active_configuration raises an
error if the device is in unconfigured state.
Note that even after set_configuration the device is still not ready.
This is still an open FIXME, and for now the device will only be
functional on the *next* invocation of liquidctl.
Documentation fixes over v1.2.0rc3 and support for additional version information.
Feature freeze: only bug or documentation fixes expected until final
v1.2.0 release.
Information available online suggests that it too is a generic Asetek
690LC device. Additionally, the legacy driver used for the later
X31/X41/X61 coolers is already very conservative.
Jonas Malaco