Logitech Bolt receivers got HID++ support at the start of the Linux 7.3 cycle, in commit 022eb347ff3a, and it is coming back out. Before that commit, a mouse on a Bolt receiver ran on the generic HID driver, with HID++ only for Bluetooth connections. The new code routed the receiver through the hid-logitech-dj driver so Bolt devices got the full HID++ treatment.
Then the bug reports arrived. Scroll wheels behaving erratically, jumping too far per tick or crawling, and settings that needed adjusting again after every reconnect, suspend and resume included. Users of 7.3 release candidates had a worse mouse than they had on 7.2.
Why it was reverted instead of patched
This morning Benjamin Tissoires posted a revert to the linux-input list and queued it for the HID tree’s 7.3 fixes branch. The commit message names two causes, and both are the interesting part. The receiver does not say which device sent which event, so with two mice on one receiver, one will be normal and the other “deadly slow or deadly fast”. And userspace also tinkers with those settings, so the new defaults landed as “users are not happy with the new default settings”. His conclusion: “the feature is not ready for a final kernel, and the sensible thing to do is to revert the patch and revisit it in a later kernel if we can work around the 2 issues I’ve mentioned above.”
The revert is small, 8 insertions against 91 deletions across hid-logitech-dj.c and hid-logitech-hidpp.c. It removes the Bolt receiver type, the explicit unpair notification handling, and the rest of the plumbing.
The path back exists. A two-patch series from Erik Håkansson builds on Rafael Passos’s earlier fix, routing Bolt wheel movement through the HID++ child so the high-resolution multiplier applies, and then honouring the scroll settings userspace has chosen. It also documents the failure mode it is working around: with the settings coming from a tool like Solaar, high-resolution events routed to the generic HID driver get scaled as if every tick were a full wheel event. The revert message links the series as the follow-up.
If this is your mouse
The revert is queued for 7.3’s fixes branch, so it reaches a 7.3 stable update rather than waiting for 7.4. Once it lands, Bolt-connected devices go back to the generic HID driver: the HID++ extras come back over Bluetooth only, and the scroll wheel behaves again. If your Bolt mouse has been misbehaving on a 7.3 release candidate, this is why, and there is nothing to configure in the meantime.
My read
This is the merge window working the way it is supposed to. The feature looked fine, users found the failures, and the maintainer took it out before the release instead of shipping three quarterly fix-ups. The systemic detail is harder to fix than the code: the receiver itself does not attribute events to devices, and userspace is a second writer to the same settings, so any future attempt has to survive both.
Sources: the revert patch and its commit message on the linux-input list, the follow-up fix series, the original commit, and Phoronix’s report