The response from the device may contain non-nil bytes beyond the range
applicable to the command being replied to.
This is generally taken care of by LINEAR11, ULINEAR16, or when reading
a single byte. However, as we weren't sure how many bytes could actually
be returned by _get_timedelta, it was allowed to try and parse the
entire response as an integer.
That was fine since we were reading with little endianess, and no
devices were known that actually send extra non-nil bytes. That has
changed with the H1500i: only 4 bytes can be safely read from the
response.
Fix _get_timedelta with this new information.
Fixes: #575
Fixes: 64523ef337
A rare and so far not well understood issue with these PSUs has been an
occasional exception being thrown from timedelta:
OverflowError: Python int too large to convert to C int
In both cases for which we have debug infos, #463 and #192 (part), it
seems that the cause is an invalid response from the PSU, probably
because of a race with another program simultaneously accessing it.
(A third case has been reported on Discord, but so far no debug info has
been provided to us. Still, it seems likely that once again there's
another program (iCue) in use at the same time as liquidctl).
Check the response matches the command sent in _exec, and if that fails,
suggest that a possible conflict with another program might be the
cause.
Also fix a small issue with how the mock used for unit testing
automatically preloads reports for future impending reads, which up to
this point failed to consider the write bit (which, for the OCP mode,
can be both write=0 or read=1).
Fixes: #463
Related: #192
* Initial sensor reading support from hwmon for X53 and Z53
* Remove superflous get_status from KrakenZ3
* KrakenX3: read pump duty from hwmon, if available
* Initial support for setting fixed duty through hwmon and directly
* Refactor hwmon_ctrl_mapping info outside of classes
Will fix tests later
* Implement speed profile setting through hwmon; store only hwmon channel no in hwmon_ctrl_mapping
* Initial test fixing
* Test Z3 reading from hwmon, todo reading directly
* Separate X3 and Z3 status reports; add Z3 direct access status report testing
* Fix 1.4.x backward compatibility test
* Add changed in note to kraken 3 guide docs
* Mark Kraken Z3 with h in README
* Note Z3 in guide for hwmon as well
* Add tests for setting fixed duty directly for Kraken X3 and Z3
* Add tests for setting fixed duty through hwmon for Kraken X3 and Z3
* Add test for setting Kraken X3 speed profile directly
* Add test for setting Kraken Z3 speed profile directly
* Check pwmX_enable availability instead for setting speed profiles through hwmon
* Refactor PWM output of test curve; add test for setting Kraken X3 speed profile through hwmon
* Add test for setting speed profiles for Kraken Z3 through hwmon
* Fan has a min duty of 0% on Kraken Z3, update the guide
* Test fan report as well
* Add explanation of why we wait before setting pwmX_enable to 2
This is what we're ultimately interested in anyway. And only fetching
the driver name, instead of the module name, still works even if the
driver was built into the kernel.
Fixes: #502
Commit f749c94809 ended up with experimental names in the code, and
the final names only in the documentation. Make the code use the final
names as well.
Fixes: f749c94809
The association from sensors to corresponding components is taken from
the corsair-psu Linxu hwmon driver.[^1]
A grep-backward-compatible alternative was considered
Temperature <n> -> Temperature <n> (<location>)
... but would result in very long names. Additionally, the specific
items returned from get_status() are *not* stable.[^2][^3]
[^1]: https://www.kernel.org/doc/html/v5.11/hwmon/corsair-psu.html
[^2]: docs/developer/process.md#stability-and-backward-compatibility
This fixes a mistake from pre-1.0 liquidctl and gives us flexibility to
change the structure used to hold that data, if that turns out to be
beneficial in the future.
Additionally, the new class field is called _MATCHES, following what was
used in the later nvidia module.
As far as I can tell the only external user of this field is Coolero,
and I'll submit a patch shortly to prevent any breakage there.
Keeping a temporary alias during some deprecation period was considered,
but isn't trivial since this is a class not instance field. As there's
only a single external user, it's easier to just fix it.
Finally, a typical Coolero installation generally bundles a specific
liquidctl version, and otherwise existing global setups shouldn't go
through the affected path (before an update) since it's in a test.
Update the Commander Core to recognize the Commander Core XT Product ID,
and update channel/temperature naming across the driver to account for
the lack of an AIO on this variant of the device. Other than this, the
protocol appears identical and at least fan speed readout and control
have been tested by me.
Creating symlinks on Windows is, by default, a privileged operation.
From the `os.symlink()` documentation:
> On newer versions of Windows 10, unprivileged accounts can create
> symlinks if Developer Mode is enabled. When Developer Mode is not
> available/enabled, the SeCreateSymbolicLinkPrivilege privilege is
> required, or the process must be run as an administrator.
While it is important to test that our keyval storage is consistent even
with pathological symlinks, we shouldn't break the test suite if we're
unable to run this test because the user/developer hasn't enabled
developer mode.
Fixes: #460
The different ways the firmware version is reported by liquidctl and CAM
causes some confusion, of at least surprise; CAM nowadays uses a
simplified 2-digit form for the Smart Device V1 (and, presumably, the
Grid+ V3).
The different ways the firmware version is reported by liquidctl and CAM
causes some confusion, of at least surprise; CAM uses a simplified
2-digit form since the migration to the unified 5.x/6.x firmware.
Change how liquidctl reports the version for modern firmware to match
CAM, but retain the 3-digit form for 2.x/3.x firmware [and earlier].
Also log the raw firmware tuple with debug level.
According to our documented policy, this is not a breaking change:[^1]
> 4. The output from CLI commands is *not* guaranteed to be stable,
> 5. and neither are the items returned from `get_status()` or `initialize()`.
Additionally, some current users of that information already need to be
fixed and call/execute initialize in the first place.
Finally, this allows us to have get_status() return data from hwmon,
when possible, and where firmware and LED accessory information is not
available.
[^1]: docs/developer/process.md ("Stability and backward compatibility" section)
Jonas Malaco