Commit 2050d0b ("Traverse all hid/hidraw queued reports and return the
last one") aggressively started to clear all enqueued reports whenever a
read was done on a HID using hidapi.
While that seemed to work ok, it could cause important reports to be
lost, which might eventually break some drivers. As no contributor has
enough devices to test all drivers, it is better to be conservative and
only explicitly clear enqueued reports.
Notably, it is wiser to clear the queue before any writes that precede
one or more reads. This will clear stale data that has already been
queued, but will not risk loosing expected responses. And drivers that
expect reads to match specific writes should already be prepared to
handle what is left.
The objective is not definitively clear all previous reports, but simply
to avoid acting on (or forwarding to the user) stale data. The subtle
difference is that _stale_ presumes a delay of more than infinitesimal
length.
Related: #87 ("1.3.2 regression: kraken_two.get_status() returns wrong
fan RPM value")
As incoming HID reports are queued by the OS, HidapiDevice.read() would
return stale data to the drivers. The drivers assume the reads aren't
queued because that's not necessary with the currently supported
devices.
This didn't affect the liquidctl CLI as the connection to HIDAPI
wouldn't last long enough for too much data to be queued and lost. But
for downstream projects like GKraken this was a significant regression
from liquidctl 1.1.0.
To keep the behavior consistent between the HIDAPI and Libusb backends,
traverse all queued (incoming) reports until the last one is found, and
only return it.
Related: #87 ("1.3.2 regression: kraken_two.get_status() returns wrong
fan RPM value")
Reported-by: @leinardi
When searching for devices using find_supported_devices, the hid option
was not forwarded by UsbHidDriver to the corresponding find_devices bus
method.
As a result, it wasn't possible to select among the hid, hidraw or usb
APIs when instantiating devices this way.
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
Explicitly mentioning `--verbose` causes docopt to threat it differently
and no longer accept it as part of `[options]`.
Fixes: 229b56b70e ("Add `initialize all` variant for initializing[...]")
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")
Device IDs are unstable and costly to compute, meaning that both users
and liquidctl need to spend extra time when dealing when them.
Additionally, selecting devices by "name" is more natural.
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`
On Linux and other platforms the new RuntimeStorage object conforms to
the XDG basedir spec and supports XDG_RUNTIME_DIR, falling back to
/var/run, and reads check both possible locations. On the other hand,
/usr[/local]/share is no longer a candidate location.
The subdirectories used by the Legacy 690LC driver have dropped the
release number, but now include 'legacy' as a reference to their owner.
The base directory on Windows no longer includes the appauthor, but
remains whatever is computed by appdirs.site_data_dir. Appdirs appears
to solve quite a number of potential issues and we don't to deal with
them here (yet?).
There have been no effective changes to the base path on MacOS.
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")
Jonas Malaco