[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mouse problem.

On 2/22/22 10:15, Tim Woodall wrote:

I have a problem with my mouse which operates through a KVM switch.

Initially it works fine but once I switch away from the computer and
then switch back, the scroll wheel is "amplified".

Testing with xev I see 16 messages where I previously expected to see
one.

rmmod usbhid; modprobe usbhid
  does not fix. Removing all of hid_multitouch, usbhid, hid_generic,
i2c_hid and hid and re modprobing them also doesn't fix.

xinput set-prop 10 "Evdev Scrolling Distance" 16 1 1
  does fix it - but running this before it's gone into it's "amplified"
state makes the mouse wheel almost unusable as it needs 16 clicks to
generate one up/down event.

It appears to be only the button 4/5 scrollwheel that have this problem.
Everything else seems to work normally.

xinput list-props 10 shows no differences at all between the bad and the
good state.

Unplugging and replugging the dongle does fix it until I use the switch
box again. But unplugging the computer from the KVM box and plugging it
back in does NOT fix the problem.

$ xinput list-props 10
Device 'Microsoft Microsoft?? 2.4GHz Transceiver v8.0 Mouse':
         Device Enabled (150):   1
        Coordinate Transformation Matrix (152): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 
         Device Accel Profile (280):     0
         Device Accel Constant Deceleration (281):       1.000000
         Device Accel Adaptive Deceleration (282):       1.000000
         Device Accel Velocity Scaling (283):    10.000000
         Device Product ID (272):        1118, 1861
         Device Node (273):      "/dev/input/event8"
         Evdev Axis Inversion (284):     0, 0
         Evdev Axes Swap (286):  0
        Axis Labels (287):      "Rel X" (160), "Rel Y" (161), "Rel Horiz Wheel" (278), "Rel Vert Wheel" (279)         Button Labels (288):    "Button Left" (153), "Button Middle" (154), "Button Right" (155), "Button Wheel Up" (156), "Button Wheel Down" (157), "Button Horiz Wheel Left" (158), "Button Horiz Wheel Right" (159), "Button Side" (276), "Button Extra" (277), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275) 
         Evdev Scrolling Distance (289): 1, 1, 1
         Evdev Middle Button Emulation (290):    0
         Evdev Middle Button Timeout (291):      50
         Evdev Middle Button Button (292):       2
         Evdev Third Button Emulation (293):     0
         Evdev Third Button Emulation Timeout (294):     1000
         Evdev Third Button Emulation Button (295):      3
         Evdev Third Button Emulation Threshold (296):   20
         Evdev Wheel Emulation (297):    0
         Evdev Wheel Emulation Axes (298):       0, 0, 4, 5
         Evdev Wheel Emulation Inertia (299):    10
         Evdev Wheel Emulation Timeout (300):    200
         Evdev Wheel Emulation Button (301):     4
         Evdev Drag Lock Buttons (302):  0

Anyone ever seen anything like this and got any ideas how I can fix it?
New keyboard and mouse is an option if this is a known problem with this
model.



On 2/22/22 10:19, Tim Woodall wrote:
> In fact, unplugging the switchbox from the computer and plugging it back
> in is enough to trigger this problem. Only just thought to try that.
I have been using Microsoft Wheel Mouse Optical USB and PS/2 Compatible for 20+ years and IOGEAR 8-Port MiniView PS/2 KVM switch (GCS78KIT) for 10+ years. Finding a KVM switch that worked correctly with Windows, Linux, and FreeBSD was non-trivial.
For the past 2+ years (?), I have experienced berzerk mouse behavior with Debian 9, 10, and 11 with Xfce desktop on a Dell Latitude E6520 laptop with Intel/NVIDIA Optimus graphics -- when I move the mouse, there can be storms of rapid random mouse and keyboard events that open, close, resize, etc., Windows and/or menus, insert strings of characters that I have previously typed, etc.. It is not uncommon for the mouse pointer to be left in what appears to be a rectangular drag select mode. Moving the mouse is the trigger; especially when moving the mouse out of a window. Moving the mouse out of a Firefox window that is browsing a web site with heavy JavaScript is the most likely trigger (notably eBay and the photo viewer).
I have been unable to isolate the problem to the E6520, the KVM switch, the mouse, Debian, nouveau, or Firefox. Debian 10 has always been the worst. Debian 11 had reduced frequency, but is still unusable. Debian 9 has the least frequent problems, and is what I run on the E6520 as a daily driver.
I also have a desktop computer with an Intel DQ67SW motherboard and Intel Core i7-2600S processor (Intel HD Graphics 2000) connected to the KVM switch. Malfunctions are rare, but do occur.
My strategy over the years has been to use major brand, mass produced, commodity hardware. It is best if the hardware is at least a few years old. Intel supports FOSS, so their hardware seems to work fairly well with the FOSS I use (Debian and FreeBSD). Optimus on FOSS has been notoriously bad since day one.
I have found that as each new major revision of Debian Stable is released, it is usually broken on one or more of my machines. I must wait and re-evaluate as each new minor version is released. This strategy worked through Debian 9. Debian 10 never stabilized on the E6520 and is now EOL. We'll see if Debian 11 stabilizes.
All I can suggest is that you get extra hardware and do A-B testing to try and isolate the problem(s). Also, try Stable, Old Stable, and Old Old Stable. 


David
Reply to: