Re: [PATCH] HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2022-08-25 at 16:47 -0400, Peter F. Patel-Schneider wrote:
> This patch will cause more use of a part of the driver that
> constructs
> messages that do not conform to the HID++ 2.0 specification.  This
> makes now a good time to fix the parts of the driver that construct
> non-conforming messages.  More information follows.

This would cause problems, but not any worse than adding the product
IDs individually, which is what we're trying to avoid.

> This results in non-conforming messages being sent to devices.  As
> devices are obligated to return this nibble intact they produce non-
> conforming responses as well.  (Their other option would be to reject
> the messages.) This confuses other software that correctly uses this
> nibble to distinguish between device response messages and device
> event
> messages.

I don't understand how this...

> In particular, the response to the unified battery command to get the
> capabilities comes back with a 0x00 function byte which is
> indistinguishable from a spontaneous notification message from the
> device for a battery status event.  Other software trying to
> communicate with the device (e.g., Solaar) sees a unified battery
> status notification and will generally end up with incorrect
> information about the device.  I suspect that this is actually
> happening and is the cause of the Solaar bug report
> https://github.com/pwr-Solaar/Solaar/issues/1718

...could cause this. Can you explain what the messages would look like
in both cases, and how they could be misinterpreted as a 15 vs. 85
percent battery level?

> There is also the possibility that the driver confuses a notification
> from the device as the response to a command that it sent.  When this
> happens it would be likely that the actual response would be treated
> as
> a notification.
> 
> 
> The fix is to modify all the CMD definitions in the code to have 1 in
> their low-order nibble.

All in all, I don't see those bugs as blocking the integration of the
patch discussed above, I see it as a way to expose those bugs and
possibly a way to make them more urgent.

Filipe, were those problems known/already reported?

Cheers



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux