You are not logged in.
Hello reader,
My daily mouse is a Logitech G502 mouse.
I have started having this issue since the Linux 6.0 kernel (could be 6.1 or 6.2) was released to the LTS versions of Ubuntu. Now after I changed to Arch (finally) I have the issue again, this issue was also there back when I had a spare HDD running Arch for testing.
Words cannot express the extent of by which I am fed up with this mess and before you tell me to get another mouse, no that is not a solution, just the fact that this issue has been solved with simple tinkering is enough for me not to buy a mouse. From what I can tell I have comments on the highest ranking (in terms of Google search) results when you search this issue online.
Here are some examples of those threads:
https://www.reddit.com/r/LogitechG/comm … sensitive/
https://www.reddit.com/r/archlinux/comm … ource=link
https://bbs.archlinux.org/viewtopic.php … 7#p2091247
After some tinkering I have got my mouse to the point that it is less sensitive, but just taking it off the mat and putting it back on it makes the scroll wheel to send a twitch to the driver and make it interface with the software. I just do not know what to say, I have tried both blacklisting methods (by both I mean
sudo nano /etc/libinput/local-overrides.quirksand
sudo nano /etc/modprobe.d/killhidpp.conf). I also tried installing solaar, and with all do respect to the developer, I just cannot think of a world where they considered that there would be people using the one of, if not, the most widespread of gaming mice. The program literally has two functions, making it worse for the scroll wheel, or just turning it off (it requires a whole cycle of the wheel to scroll a single line).
Ask me anything I will try to help as much as I can.
Proof that the mf is still active.
hid_logitech_hidpp 81920 0
hid_logitech_dj 40960 0
usbhid 81920 2 hid_logitech_dj,hid_logitech_hidppThanks for reading, I hope this gets resolved and I start enjoying the tinkering side of Arch.
Last edited by AAVVIronAlex (2024-06-07 22:35:29)
Offline
Post the contents of both of these files, blacklisting the module should still work as far as I know. If you want to blacklist it harder
module_blacklist=hid_logitech_hidppin the kernel command line will completely block it regardless of whether something else would require it (which isn't the case according to lsmod, so a normal blacklist should suffice)
Offline
Post the contents of both of these files
This is the /etc/libinput/local-overrides.quirks file.
[DisableThatShitHighResolution]
MatchName=*
AttrEventCode=-REL_WHEEL_HI_RES;-REL_HWHEEL_HI_RES;And here is sudo nano /etc/modprobe.d/killhidpp.conf
install hid_logitech_hidpp /usr/bin/trueJust to be sure, I will restart now, kill power to the USB and the PC I will recycle the mouse and then we will proceed (I will edit this post when I do so). (edit is in the end of this post)
earthmapspictures@H-E-R-A-N:~$ cat /etc/modprobe.d/killhidpp.conf
install hid_logitech_hidpp /usr/bin/true
earthmapspictures@H-E-R-A-N:~$ cat /etc/libinput/local-overrides.quirks
[DisableThatShitHighResolution]
MatchName=*
AttrEventCode=-REL_WHEEL_HI_RES;-REL_HWHEEL_HI_RES;Now I need to scroll a whole cycle to make it scroll a single line, maybe it is blacklisted too hard? Because I did try to only run it with the /etc/libinput/local-overrides.quirks file changed. Restarting now without the libinput quirks file.
Without the /etc/modprobe.d/killhidpp.conf the mouse scrolls with extremely high density (just like when I had my first issues, leading me to think that the configuration there makes it worse, somehow?).
Last edited by AAVVIronAlex (2024-06-07 06:37:42)
Offline
Check what's being received https://wayland.freedesktop.org/libinpu … hires.html and match the quirks precisely, https://wiki.archlinux.org/title/Logite … X_Master_3 (don't copypaste the IDs there, figure the ones for your device)
However:
After some tinkering I have got my mouse to the point that it is less sensitive, but just taking it off the mat and putting it back on it makes the scroll wheel to send a twitch to the driver and make it interface with the software.
If that means that the wheel generally acted with expected pace but would still fire on a hair-trigger: do you simply have it in free-spinning mode???
https://www.reddit.com/r/LogitechG/comm … g502_hero/
Offline
Check what's being received https://wayland.freedesktop.org/libinpu … hires.html and match the quirks precisely, https://wiki.archlinux.org/title/Logite … X_Master_3 (don't copypaste the IDs there, figure the ones for your device)
I just changed the contents of the file to this:
[Logitech G502 high resolution scrolling]
MatchVendor=0x46D
MatchProduct=0x407F
MatchName=*
AttrEventCode=-REL_WHEEL_HI_RES;-REL_HWHEEL_HI_RES;I got the Vendor and Product numbers from these commands:
earthmapspictures@H-E-R-A-N:~$ sudo libinput list-devices | grep G502 -A 5 | grep Kernel | awk '{print $2}'
[sudo] password for root:
/dev/input/event3and
earthmapspictures@H-E-R-A-N:~$ udevadm info -a /dev/input/event3 | grep id/
ATTRS{id/bustype}=="0003"
ATTRS{id/product}=="407f"
ATTRS{id/vendor}=="046d"
ATTRS{id/version}=="0111"If that means that the wheel generally acted with expected pace but would still fire on a hair-trigger: do you simply have it in free-spinning mode???
That is not the case, the hardware button is toggled and it locks into position, the reason why it triggers is because the trigger zones are not in the correct positions.
Edit: Restarting after this change did not change anything.
Last edited by AAVVIronAlex (2024-06-07 08:37:25)
Offline
If you want to blacklist it harder
module_blacklist=hid_logitech_hidppin the kernel command line will completely block it regardless of whether something else would require it (which isn't the case according to lsmod, so a normal blacklist should suffice)
So I just add this to the parameters of systemd-boot? After the nvidia.drm?
Offline
Yes, but the install method should lead to the same logical end result, so I wonder how it's possibly still loaded, unless the module is in the initramfs for some reason.
FWIW so we don't run in circles.
sudo libinput debug-eventsgives you what kind of output when scrolling the wheel?
Last edited by V1del (2024-06-07 09:18:09)
Offline
Yes, but the install method should lead to the same logical end result, so I wonder how it's possibly still loaded, unless the module is in the initramfs for some reason.
Here is what the output of that gives me. (event3 is the mouse indeed (judging from the previous commands))
event3 POINTER_SCROLL_WHEEL +38.133s vert 15.00/120.0* horiz 0.00/0.0 (wheel)Offline
If the "vert 15.00/120.0*" remains uniform/the same for all scroll events then high res scrolling is disabled for all intents and purposes on an OS/libinput level, and whatever issues you have will be internal to the mouse/firmware settings. So far the logistics that would be enabled by the module, I know of at least one bug with my specific model (G903, as discussed in the earlier thread you linked) where the mere act of asking whether the device supports hidpi lead to breakage of scrolling and it generating normal "POINTER_SCROLL_WHEEL" events at a increased rate, so filtering for hi_res would mean nothing. But that got disabled for direct USB access as a response to that -- and not loading hid_logitech_hidpp would also omit said query from happening.
Make sure hid_logitech_hidpp is really not loaded now, then unplug and replug the device (maybe also test to omit the dj receiver and plugging the mouse directly, does the behaviour change?)
Other than those, get yourself to a Windows with the logitech hub software, and check whether you can do more fine grained/correct settings there and whether you can persist those to the device.
Offline
This is the output I get when I lsmod and grep hid:
mac_hid 12288 0
hid_logitech_hidpp 81920 0
hid_logitech_dj 40960 0
hid_generic 12288 0
usbhid 81920 2 hid_logitech_dj,hid_logitech_hidppIt does not do it when plugged into the wire directly to the pc, but it does do it when I return back to the wireless mode. I cannot use it wired though.
Last edited by AAVVIronAlex (2024-06-07 13:11:16)
Offline
I'm not sure why that blacklist nor why the modprobe version wouldn't work.
Does
sudo modprobe -r hid_logitech_hidppgive you an error? Or correctly remove the module? What's the behaviour when you replug the device/the wireless receiver after unloading that
Offline
That seemed to fix it.
Now lsmod | grep logitech gets me:
hid_logitech_dj 40960 0
usbhid 81920 1 hid_logitech_djShould I just enable this in KDE as a startup script that should be run? Actually now that I think of it I would have to grant sudo permissions...
Offline
There is no way in hell that "module_blacklist=hid_logitech_hidpp" would allow the module to be loaded no matter what tries how hard and "install hid_logitech_hidpp /usr/bin/true" would rather unlikely allow the module to be loaded (you could still insmod it)
cat /proc/cmdline
modprobe -c | grep hid_logitech_hidpp | grep -v aliasIf you want to rely on the modiprobe.conf variant, make sure to regenerate the initramfs to pick up the config in case the module exists in the initramfs and gets loaded early.
Offline
earthmapspictures@H-E-R-A-N:~$ cat /proc/cmdline
initrd=\initramfs-linux.img root=PARTUUID=e4bccff7-9cca-499b-94a0-da275bed16c4 rw nvidia-drm.modeset=1earthmapspictures@H-E-R-A-N:~$ modprobe -c | grep hid_logitech_hidpp | grep -v alias
blacklist hid_logitech_hidppThings seem to be okay. At least that is what I see. The blacklist is in place, and the first code block is basically the systemd-boot options I configured during the install.
If you want to rely on the modiprobe.conf variant, make sure to regenerate the initramfs to pick up the config in case the module exists in the initramfs and gets loaded early.
As for this, yes I would like to know how to remove that thing from the early loading scene. It is being loaded somehow, right?
Offline
That's a weak blacklist, the module can still be loaded explicitly or dragged in by another module.
For this to have any chance to work you'll have to use the install /bin/true method or you use the module_blacklist parameter (which is currently not in place, see your cmdline) which will not allow the module to be loaded no matter what.
Offline
module_blacklist parameter
Like this?
module_blacklist hid_logitech_hidpp /usr/bin/trueLast edited by AAVVIronAlex (2024-06-07 20:27:03)
Offline
No.
https://wiki.archlinux.org/title/Kernel … acklisting
"module_blacklist=hid_logitech_hidpp" would be a https://wiki.archlinux.org/title/Kernel_parameters
And the alternative modprobe config would be "install hid_logitech_hidpp /bin/true"
Offline
"module_blacklist=hid_logitech_hidpp" would be a https://wiki.archlinux.org/title/Kernel_parameters
So do I just restart?
module_blacklist=hid_logitech_hidppAdded this to the file (/etc/modprobe.d/killhidpp.conf).
Last edited by AAVVIronAlex (2024-06-07 21:22:55)
Offline
What file?
Again, that's a kernel parameter, is has not business or function in any modprobe.conf file - for systemd-boot it would go into the options line of the used loader.conf, see eg. https://wiki.archlinux.org/title/System … ng_loaders
Offline
Okay so I reverted that, now I have this as the kernel parameters line in my systemd-boot configuration file:
options root=PARTUUID=e4bccff7-9cca-499b-94a0-da275bed16c4 rw nvidia-drm.modeset=1 module_blacklist=hid_logitech_hidppIf this is okay, I will do:
bootctl updateWhich will update the configuration that we checked with:
cat /proc/cmdlineIf this is all okay, tell me, I will do the update and reboot.
Last edited by AAVVIronAlex (2024-06-07 21:57:01)
Offline
SOLUTION
Just adding it worked. I added the kernel parameter module_blacklist=hid_logitech_hidpp worked. That was added in the sudo nano /boot/loader/entries/[your_configuration_name].conf configuration file. No need to update systemd-boot.
Now the output of:
earthmapspictures@H-E-R-A-N:~$ lsmod | grep logitech
hid_logitech_dj 40960 0
usbhid 81920 1 hid_logitech_djThis does not have the "hid_logitech_hidpp 81920 0" and "usbhid 81920 2 hid_logitech_dj,hid_logitech_hidpp" indicating that the module has not been loaded.
Thank you all for helping.
Wish you the best!
Offline
This sounds like the same issue I struggled with a couple years ago, and when I recently reinstalled my system from scratch I had to figure out how I fixed it before. Please excuse me if it's a different issue.
Basically scrolling was overly sensitive and was most noticeable when trying to scroll through images as it would scroll 2-3 at a time when I had the scroll wheel set to indented instead of free scrolling. (M705, MX Master 2S)
The fix for me was to add the file 99-libinput-no-hires-scroll.conf to my /etc/X11/xorg.conf.d/ folder.
Section "InputClass"
Identifier "Disable high-resolution scrolling"
MatchDriver "libinput"
Option "HighResolutionWheelScrolling" "off"
EndSectionHere is where I got the information from thanks to the libinput devs.
https://gitlab.freedesktop.org/libinput … issues/675
Offline
This sounds like the same issue I struggled with a couple years ago, and when I recently reinstalled my system from scratch I had to figure out how I fixed it before.
Your issue is the same, but mine was on Wayland, I have not used X11 in a long time. X11 will not work for me considering that I have mismatched monitors (different resolutions and refresh rates). Blacklisting it was the fix for me.
Offline
@akovia The problem is that even if you filter out the high res events (the libinput quirk config posted here should lead to that effect) "something" in the code asking the mouse to enable hidpi can lead to weird firmware internal behaviours, and this is kernel module/firmware level, nothing you're doing in the upper layers will logically fix this correctly.
Offline