On Wed, 2022-12-07 at 10:47 +0100, Rafael J. Wysocki wrote:

On Wed, Dec 7, 2022 at 10:29 AM Bastien Nocera [off-list ref]
wrote:

quoted

On Wed, 2022-12-07 at 10:12 +0100, Rafael J. Wysocki wrote:

quoted

From: Rafael J. Wysocki <redacted>

Evidently, Logitech Bluetooth Mouse M336/M337/M535 (0xb016) does
not
work when HID++ is enabled for it,

This needs the output of the hidpp-list-features tool mentioned
earlier
in the thread so we can avoid words like "evidently" and provide
concrete proof.

Well, so point me to a binary of this, please.

quoted

But why is it needed in this case?

Because it doesn't work otherwise.

quoted

We purposefully try to avoid blanket
blocklists. The lack of HID++ can be probed, so the device should
work
just as it used to (if the fallback code works).

No, because the hid-generic driver has no way to check that the probe
function of your driver fails for this particular device.  The
probing
of hid-generic will fail so long as the device matches the device ID
list of any specific HID driver.  With patch [1/2] from this series
applied this is unless that specific driver has a ->match() callback
rejecting the given device.

You'd need a list of drivers that have been tried and failed
somewhere
for that and AFAICS no such list is present in the code.

This code will start the generic HID stack if the device doesn't
support HID++:
        hidpp->supported_reports = hidpp_validate_device(hdev);

        if (!hidpp->supported_reports) {
                hid_set_drvdata(hdev, NULL);
                devm_kfree(&hdev->dev, hidpp);
                return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
        }

But in your case the device supports HID++ enough to go past that, but
fails to get the HID++ version, which makes the driver think it's not
connected, and just bails.

So a minimum fix for 6.1 that actually works for me is to add the
non-working device to the blocklist.  More sophisticated stuff can be
done later.

quoted

We should only list devices that need special handling, and the
ones
that don't work once HID++ was probed unsuccessfully.

quoted

 so add it to the list of devices
that are not handled by logitech-hidpp.

Fixes: 532223c8ac57 ("HID: logitech-hidpp: Enable HID++ for all
the
Logitech Bluetooth devices")
Signed-off-by: Rafael J. Wysocki <redacted>
---
 drivers/hid/hid-logitech-hidpp.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-pm/drivers/hid/hid-logitech-hidpp.c
=================================================================
==

--- linux-pm.orig/drivers/hid/hid-logitech-hidpp.c
+++ linux-pm/drivers/hid/hid-logitech-hidpp.c

@@ -4274,6 +4274,7 @@ static const struct hid_device_id unhand

        { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_HARMONY_PS3) },
        /* Handled in hid-generic */
        { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_DINOVO_EDGE_KBD) },
+       { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb016) },
        {}
 };