Logitech Mouse wheel movement not correctly executed

English Hardware
1

Hi there,

I have on my PC (OS42.1 installation) the problem that if I use my mouse wheel to scroll screen content up- and downward, the upward scrolling does not work as expected. It’s working, but it seems to miss sometimes 1 or 2 movements of the wheel.You turn the wheel and … nothing happens. You turn it again and it moves a bit. You turn it a3rd time and it make a normal move.

I experienced the same problem in the virtualbox Win7 (64) running under the OS42.1 OS with firefox, IBM Notes and other applications.
As this virtual machine probably depends on the OS42.1 concerning the mouse movements, it did not surprise me.

I have also on the same PC a Win7 pro 64 partition (independent of OS42.1, no virtual machine) , where this problem does not appear - same applications like firefox, IBM Notes etc. as in the virtual machine or in the OS42.1. I first thought it could be a mouse / hardware problem, but the fact that it does not happen in this Win7 installation, allowed me to drop this idea.

Have some of you guys got a similar experience ? I assume that it could be a kind of timing problem - not polling often enough -> mouse buffer overrrun !?!?

TIA, Joe

2

I note that there seem to be a large number of hits returned for various Logitech scroll wheel problems. Some windows users have to enable ‘"Use MS office compatible scroll only’ and similar settings which aren’t available for Linux users. You might want to share the model details

cat /proc/bus/input/devices

/usr/sbin/hwinfo --mouse

It is likely that the generic usbhid driver is supporting the device in question… you can check this with

usb-devices

*Look for the output bock pertaining to the device (chipset) in question.

If usbhid is in use, then I note that ‘modinfo usbhid’ shows the following parameters available

parm:           mousepoll:Polling interval of mice (uint)
parm:           ignoreled:Autosuspend with active leds (uint)
parm:           quirks:Add/modify USB HID quirks by specifying  quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp)

It may be that adjusting the polling interval might help or perhaps quirks exist for this model. The usbhid module can be loaded at boot with the required options by creating a configuration file in the /etc/modprobe.d/ directory. you might need to research this further outside of these forums. If none of these things help, then it may be that a bug report needs to be submitted.

3

Thanks for your reply !

As I never had such problems in OpenSuse 13.1 and 13.2 , changes in LEAP must be responsible for these bug(s).

TIA for your support !

Joe

Below the outputs you asked for:

cat /proc/bus/input/devices

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name=“Power Button”
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name=“Power Button”
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name=“PC Speaker”
P: Phys=isa0061/input0
S: Sysfs=/devices/platform/pcspkr/input/input5
U: Uniq=
H: Handlers=kbd event2
B: PROP=0
B: EV=40001
B: SND=6

I: Bus=0019 Vendor=0000 Product=0000 Version=0000
N: Name=“Eee PC WMI hotkeys”
P: Phys=eeepc-wmi/input0
S: Sysfs=/devices/platform/eeepc-wmi/input/input6
U: Uniq=
H: Handlers=kbd event3 rfkill
B: PROP=0
B: EV=100013
B: KEY=7e40000 0 800000000000 0 0 1400b00100000 300180001100800 e000000000000 2
B: MSC=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI HDMI HDMI/DP,pcm=3”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input7
U: Uniq=
H: Handlers=event4
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Front Mic”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input8
U: Uniq=
H: Handlers=event5
B: PROP=0
B: EV=21
B: SW=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Rear Mic”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input9
U: Uniq=
H: Handlers=event6
B: PROP=0
B: EV=21
B: SW=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Line”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input10
U: Uniq=
H: Handlers=event7
B: PROP=0
B: EV=21
B: SW=2000

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Line Out Front”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input11
U: Uniq=
H: Handlers=event8
B: PROP=0
B: EV=21
B: SW=40

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Line Out Surround”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input12
U: Uniq=
H: Handlers=event9
B: PROP=0
B: EV=21
B: SW=40

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Line Out CLFE”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input13
U: Uniq=
H: Handlers=event10
B: PROP=0
B: EV=21
B: SW=40

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Line Out Side”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input14
U: Uniq=
H: Handlers=event11
B: PROP=0
B: EV=21
B: SW=40

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name=“HDA ATI SB Front Headphone”
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input15
U: Uniq=
H: Handlers=event12
B: PROP=0
B: EV=21
B: SW=4

I: Bus=0003 Vendor=046d Product=c52e Version=0111
N: Name=“Logitech USB Receiver”
P: Phys=usb-0000:00:13.0-3/input0
S: Sysfs=/devices/pci0000:00/0000:00:13.0/usb9/9-3/9-3:1.0/0003:046D:C52E.0001/input/input16
U: Uniq=
H: Handlers=sysrq kbd event13
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff800000000007ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=046d Product=c52e Version=0111
N: Name=“Logitech USB Receiver”
P: Phys=usb-0000:00:13.0-3/input1
S: Sysfs=/devices/pci0000:00/0000:00:13.0/usb9/9-3/9-3:1.1/0003:046D:C52E.0002/input/input17
U: Uniq=
H: Handlers=kbd mouse0 event14
B: PROP=0
B: EV=1f
B: KEY=3007f 0 0 483ffff17aff32d bf54444600000000 ffff0001 130f938b17c000 677bfad941dfed 9ed68000004400 10000002
B: REL=1c3
B: ABS=100000000
B: MSC=10

/usr/sbin/hwinfo --mouse

53: USB 00.1: 10503 USB Mouse
[Created at usb.122]
Unique ID: 5FUz.UIAsw8YNWF0
Parent ID: KgLP.erpEvbsFWX1
SysFS ID: /devices/pci0000:00/0000:00:13.0/usb9/9-3/9-3:1.1
SysFS BusID: 9-3:1.1
Hardware Class: mouse
Model: “Logitech MK260 Wireless Combo Receiver”
Hotplug: USB
Vendor: usb 0x046d “Logitech, Inc.”
Device: usb 0xc52e “MK260 Wireless Combo Receiver”
Revision: “23.00”
Compatible to: int 0x0200 0x0001 “Generic USB Mouse”
Driver: “usbhid”
Driver Modules: “usbhid”
Speed: 12 Mbps
Module Alias: “usb:v046DpC52Ed2300dc00dsc00dp00ic03isc01ip02in01”
Driver Info #0:
XFree86 Protocol: explorerps/2
GPM Protocol: exps2
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #51 (Hub)

usb-devices

T: Bus=09 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046d ProdID=c52e Rev=23.00
S: Manufacturer=Logitech
S: Product=USB Receiver
C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=98mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid

4

As I never had such problems in OpenSuse 13.1 and 13.2 , changes in LEAP must be responsible for these bug(s).

Thanks for the hardware info. You seem pretty sure that the scroll wheel doesn’t need cleaning, but I’d check that anyway. You could try adjusting the mousepoll (polling rate), although it’s not clear to me that this is the problem. See here. Create /etc/modprobe.d/usbhid.conf with entry similar to

options usbhid mousepoll=4

Save when done, then reload the driver to make it take effect

modprobe -r usbhid && modprobe usbhid

You can check the applied options with

systool -v -m usbhid

If you have openSUSE available for testing, you could try upgrading the kernel to see whether it then exhibits the same issue. I’ve seen similar issues reported which were attributable to problems higher up the input stack (in the X-server), but in your case you’ve already mentioned that Windows guest OS is affected as well as Linux host, so that tells me kernel-level issue of some kind.

5

@J0EE0J: Have you tested to see if another Mouse (preferably from the same manufacturer and, preferably the same model) is the exhibiting the described behaviour on the affected system?
[HR][/HR]All hardware has a “Mean time between failures” (MTBF) – occasionally Hardware is “dead on arrival” (on delivery, unpack it, try it, it misbehaves) – occasionally Hardware “dies after 5 minutes of use” – if you’re lucky, it behaves as expected – until it dies . . .