Alright. A little bit on background on this mouse and some other Logitech ones.
A little bit more than 12 years ago I started working on the Logitech HID++ protocol at Logitech’s request. Basically, they thought that standard HID was not enough for their need and created a rather complex protocol on top of it.
For the curious, they opened part of their spec and I wrote the first iteration of the hid-logitech-hidpp.ko kernel driver. Solaar then came in and is also “supported” by Logitech (i.e. they are in good terms and Logitech can share specs to the developers when they need).
What matters here is that they are using 2 Logitech specific report IDs:
0x11. And you are seeing them here.
So every time you get those reports, you have to follow the entire spec to make sense out of it (Solaar does it for you and the kernel too to some functions).
So as you discovered, when you receive
ReportID: 17 /Vendor Defined Page 1 ['01', '0e', '10', '01', ... this is a notification from the mouse to tell you the state of the “smart shift” mode. And also, as you realized there is no “release” event as this is a state of the mouse that changed, not a button notification.
Luckily, the function
0x1b04 (and probably another) allows to remap or divert any button.
By using “divert” on the smart shift button, you’ll get the notification from the mouse on the HID++ protocol that the button has been pressed/released. However, that doesn’t change the mouse behavior and the ratchet mode on the wheel will also be enabled/disabled every time you click on the button, which is not what you want. (Also this will be on a private channel, the HID++ one which is not reported as mouse events by the kernel).
By remapping the button, this is exactly what you want: the smart shift mode is disabled on the mouse, and the button is remapped to middle click by the mouse itself.
This is nice, but those mice are not capable of storing their current state when powered off. For that you need a mouse from the gaming series. Which means that every time the mouse disconnects or if you reboot your machine, you need to set the mouse to the proper mode.
And just to be clear: this is a mouse/vendor specific that is completely independent of the software stack we use on Linux. We just don’t get enough information from the mouse to be able to remap the smart shift in the upper layers. We have to send a command to the mouse for it to behave “properly”.
So, what can be done?
- rely on Solaar all the time (it’s a daemon, and it’s buggy in your case, so it needs fixes)
- or listen to what Solaar sends to the device, and write a small python (or whatever) script that sends that exact command when triggered by a udev rule when the mouse connects.
Luckily, your mouse is connecting only though Bluetooth, and so I think you don’t need the full daemon because the mouse should reconnects when we need to send the command.
In a private message you asked me whether HID-BPF would work for that use case, and I don’t think it’s worth it: we can configure the mouse to do the exact thing you want, and we have to configure the mouse anyway.
HID-BPF reacts only to mouse events. You’ll need a userspace helper to send back information to the mouse as we need to be in a separate context than the one from the event. So a small python script will be much easier.