On 8/29/22 09:41, Bastien Nocera wrote:
On Fri, 2022-08-26 at 11:37 -0400, Peter F. Patel-Schneider wrote:
Looking at
https://bugzilla.kernel.org/show_bug.cgi?id=215699 reminded me of
another problem with the driver code. Several HID++ 2.0 features,
including
the HiRes Wheel, have commands with bit fields in them and set all
the bits in
the bit field at once. But when the driver code sets the high-
resolution bit
for this feature it also sets two other bits, ignoring their current
setting.
This prevents other software from reliably using these two other
bits, one of
which is for reporting wheel movement in the opposite direction, a.
k. a.
natural scrolling.
It would be useful for the driver code to first get the other bits
and set
them to their retrieved values.
Do you have any other examples of this? For the classic Linux desktop,
this particular bug isn't something we'd hit, as natural scrolling is
implemented at the higher levels (libinput) rather than something we
expect the driver to support.
I looked and I didn't find any other examples of this in the driver. The only
HID++ command with this feature that is used by the driver, as far as I could
tell, is
#define CMD_HIRES_WHEEL_SET_WHEEL_MODE 0x20
of
#define HIDPP_PAGE_HIRES_WHEEL 0x2121
The way Solaar users see this bug is that if they use this feature to set
reverse scrolling sometimes the driver flips the bit off after Solaar flips
the bit on. If a user doesn't use Solaar or some other software that changes
devices behaviour using HID++ commands then they won't see any problem. (The
could have a multi-host mouse, use Logitech software to flip the bit, and then
when they change hosts to a Linux host the Linux driver would flip the bit.)
peter
