Need a solution similar as for https://bugzilla.kernel.org/show_bug.cgi?id=216885 but for the usb dongle. hid_is_usb(hidpp->hid_dev) always return 0 for the usb dongle. Through bluetooth it's working fine as hid_logitech_hidpp is not loading for this mouse with over BT mode.
can you please attach the output of lsusb.py
and might be helpful to attach dmesg output with the usb dongle connected as well
Created attachment 304166 [details] dmesg
Created attachment 304167 [details] lsusb
Sure, see attachments. Also, might be useful to add module option to disable hires scroll
FWIW, I forwarded your report to the developers: https://lore.kernel.org/all/5fa67291-98d0-c8d5-ca71-5a86b9adff41@leemhuis.info/ [btw, did this actually work in earlier kernel like 6.0? it sounded like it, but when I wrote that mail I started to become unsure]
I think you right. I believe this is regression introduced by hires detection instead of quirk list. Tried it on 5.15(I don't have 6.0) - no issues. It is detected right, this mouse has hires scroll, but it is works not well. Hiress scroll works, I can see hires events in evtest, but it does this for some weird way as applications sometimes miss reaction for the wheel, another application can't stable scroll forward-backward and stay on the same position(for example drop-down menus). I'm not sure where is the problem hides. I tried both x11 and wayland - same problems. Feels like it sends non-hires events not accurate. If you need additional information/logs - feel free to ask.
Hm, looks like it's not a kernel side problem. It is application layer problems. Since kernel starts support for hires events for all supported logitech mouses and libinput already has hires support - it is broke userspace, as it is seems not ready yet for hires wheels. I created quick for disable hires events by libinput and seems it helps. Maybe someone will be interested: /etc/libinput/local-overrides.quirks: [Logitech MX Anywhere 3] MatchVendor=0x46D MatchProduct=0x4090 AttrEventCode=-REL_WHEEL_HI_RES;-REL_HWHEEL_HI_RES; I'm sorry for this false alarm. I updated the kernel and ran into a problems, so thought this is regression
I'm going to close this then. For what it's worth, it was unlikely to be the same problem as https://bugzilla.kernel.org/show_bug.cgi?id=216885 as this particular bug only happened on wired connections: the device, when used on USB, has separate USB interfaces for HID++ events and HID events (including wheel events) which the HID++ driver knows nothing about. This most certainly wasn't the case with your mouse's wireless dongle. The problem looks like it's with your compositor, desktop environment or apps which don't handle hi-res scroll wheels.