Instead, add colons (when appropriate), which are picked up by
espeak-ng, and hopefully other screen readers too.
To keep some visual separation between the heading (device description)
and the status items, add a horizontal rule. This doesn't seem to
negatively affect espeak-ng.
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
Additionally to updating the range in the main (README and CLI)
copyright notices:
- remove the "(C)" and other variations of a (pseudo-)copyright symbol,
as they are redundant with the word "Copyright";
- remove dates from the notices in all other files, except those in
`extra/contrib`, as they are already more accurately tracked in git,
and also generally understood to be unnecessary (see [1], [2], [3]);
- add a few missing docstrings, including the appropriate copyright
notice, to a few modules (this also improves the output of pydoc);
- add "and contributors" when missing to existing notices;
- update links to the list of SPDX Short Identifiers, as they have
broken over time.
External copyright notices, as well as those in `extra/contrib`, are
left unchanged.
[1]: https://github.com/curl/curl/pull/10205/files
[2]: https://hynek.me/til/copyright-years/
[3]: https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects
Mostly fix a few typos and improve a few sentences. But also bring back
the "Other issue", as Discussions are not the best place for actionable
(but still non-bug) issues or feature requests.
Related: 84390f8408
Related: #537
* 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
Jonas Malaco