On Wed, 2022-12-07 at 10:48 +0100, Benjamin Tissoires wrote: > On Wed, Dec 7, 2022 at 10:29 AM Bastien Nocera <hadess@xxxxxxxxxx> > wrote: > > > > On Wed, 2022-12-07 at 10:12 +0100, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > > 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. > > > > But why is it needed in this case? 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). > > If I read the probe function correctly, we should have the HID++ > reports present, so a static analysis will not allow us to detect > that > information. > > However, this reminds me of the Litra Glow[0]. On this device, > hidpp_root_get_protocol_version() also reports an error when it is > obvious it is connected. On the Litra Glow, the error isn't HIDPP_ERROR_RESOURCE_ERROR, but HIDPP20_ERROR_UNSUPPORTED (0x09). I have a patch to add those constants to the driver. > And AFAICT, a BLE device is supposed to always be connected when it > is > presented to the kernel (because disconnect is handled in the BLE > layer, in bluez). > > Apparently Rafael's mouse is Bluetooth classic, so I have a doubt on > what happens when it goes into low power. It would probably just disconnect after a timeout. Reconnection isn't as fast as with BLE, but it's fast enough. > > We should only list devices that need special handling, and the > > ones > > that don't work once HID++ was probed unsuccessfully. > > > > Given the current state of Rafael's mouse it goes into the second > category. But I suspect we should be smarter in the probe's decision > to consider if a device is connected or not. Sure, and that's the data I'm trying to get out of the device. > > Cheers, > Benjamin > > [0] > https://lore.kernel.org/linux-input/CABfF9mO3SQZvkQGOC09H5s7EEd2UGhpE=GYB46g_zF3aEOVn=Q@xxxxxxxxxxxxxx/ >
