While RGB control hasn't been tested, it is assumed to behave as in the
previous variants. This is supported by a similarly timed new variant
of the Kraken X3 being fully backward compatible (see #503).
Fixes: #485
Suggested-by: @johandc
PR #491 unexpectedly changed the encoding the of 71-liquidctl.rules:
$ file extra/linux/71-liquidctl.rules
extra/linux/71-liquidctl.rules: Unicode text, UTF-16, little-endian text, with CRLF line terminators
Regenerate the file and change it back to UTF-8:
extra/linux/71-liquidctl.rules: Unicode text, UTF-8 text
Fixes: #491
Fixes: 747af54660
Cc: @aleksamagicka
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.
Removes extra/linux/modules-load.conf, and the need to install it.
The module is also only loaded if a supported i2c device is found.
That said, the entire i801_smbus (and, soon, i2c_piix4) counts as a
"supported i2c device", so i2c_dev will generally be loaded.
Additionally, a small downside to this approach is that, if the module
was loaded due to one of these rules, it is no longer possible to unload
it with modprobe -r.
Still, overall, this simplifies packaging and will probably be a net
positive change.
Continues PR #234, with a substantial number of small fixes and changes.
The tests still need to be ported to pytest, and there are also some
open questions in driver.
This commits changes a couple things in the probing logic for these
graphics cards.
First, when probing is done *without* enabling the required unsafe
features, and thus without actually testing the candidate addresses,
the driver instance will now use a sentinel address.
Methods that try to read or write to the device will first compare the
address to the sentinel and, if they match, abort with an AssertionError
exception. As a failsafe, the sentinel address is chosen intentionally
large so that if a method fails to do this check, the address will
likely still be refused by the lower level APIs and, ultimately, the bus
itself.
Second, probing only returns at most one driver instance, regardless of
how many addresses matched the handshake phase. The rationale for this
is that if a single address implements all necessary features, as this
driver assumes, then there is no reason expose to the user multiple
handles to the *same* device.
The tests were updated to reflect these changes, and some additional
test cases were included. A few bugs in the tests were also discovered,
and were caused by the use of driver instances probed without
`unsafe=<features>`; this is precisely what the sentinel address tries
to prevent.
For some reason I was not able to make the SUSYSTEMS (or SUBSYSTEM) key
to produce the desired results on Linux 5.9.9. As a workaround, this
rule uses the KERNEL key.
Stefano Raneri