Red Hat Bugzilla – Bug 123273
Erratic mouse behaviour when using KVM switch to return to Fedora box
Last modified: 2007-11-30 17:10:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
The mouse works fine normally and is set to the following in the
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
but my mouse is connected to the box through a KVM swtich (Belkin
Omniview Soho 4-port PS/2 version).
When I switch to an alternate box and back again to the Fedora box,
the mouse is uncontrollable and behaves erratically. The slightest
movement makes the mouse jump randomly around the screen, clicking and
selecting items, even though I'm not touching the buttons.
Only restarting the PC cures the problem, but re-occurs when you use
the KVM switch again. Restarting the X server does not cure the problem.
If you switch to tty1 and move the mouse (after the problem has
started), you get the following printed out each time you move the
mouse (although the number of bytes will vary):
psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization,
throwing 2 bytes away.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Connect PC to KVM switch
2. Switch to alternate box
3. Switch back to fedora
Actual Results: Erratic mouse behaviour
Expected Results: Mouse performs as normal
I used to be able to implement a work around in FC1 by setting the
Protocol to "MouseManPlusPS/2" with the Device to "/dev/psaux" in the
This unfortunately no longer works.
The protocol change has no effect on its own, and if I try and use
/dev/psaux, the X server fails to start. From what I can gather
/dev/psaux is to be no longer used.
The behaviour sounds similar to that in bug report 121877, except I'm
not using a laptop, the problem does not go away, and I have no
I had some feedback from Belkin who stated the following:
"This problem can occur when there is a clash between the firmware of
the switch and the mouse drivers used. Please try some different
As the psaux driver used to work with the "MouseManPlusPS/2"
protocol, is it possible to bring that back?
For your information I have a Microsoft Optical Mouse and a Belkin
SOHO 4 ports KVM.
It works fine with Windows XP, it used to work with RH9 (although I
had to switch from video to text to video mode), but I can't get it to
work with Fedora Core 2.
I am also encountering the same problem. Using a Microsoft
IntelliMouse PS/2 mouse with a Belkin OmniView 2-port KVM, switching
between Windows 2000 Pro and Fedora Core 2 test 3 (Kernel 2.6.6-
1.370). tty1 also gives the same error message "psmouse.c: Wheel
Mouse at isa0060/serio1/input0 lost synchronization, throwing [n]
I had the same problem with RH 9, after changing drivers the problem
was gone. I now have the same problem with Fedora Core 2 and i cant
seem to be able to get rid of it in any way.
I too am (or was) having the same problem. I have a Belkin Optical
mouse issues with my Belkin SOHO KVM. Try this - I got it from
another similar bug: Add 'psmouse.proto=bare' to the kernel options
when booting. It seems to resolve my problem.
Thanks for that, it did the trick.
I can now go ahead with upgrading to FC2 on my main box, without
worrying about my mouse going crazy.
Keep in mind that, if you have a wheel mouse the wheel will not work.
Reply to comment 1:
>Only restarting the PC cures the problem, but re-occurs when you use
>the KVM switch again. Restarting the X server does not cure the
This implies that it is a problem either in the kernel driver (which
is what X uses nowadays for mice), or a hardware problem. It is
possibly a protocol stream synchronization issue caused by the
KVM which puts the kernel driver out of sync with the hardware.
This problem is very common in many KVM switches.
Unfortunately, some KVM switches may work with Linux/X, others may
not. I use an ABL Masterview 4 port PS/2 KVM, and it works fine in
all OS releases so far, with any hardware I've plugged into it,
including the mouse wheel. I use the "IMPS/2" protocol, and use a
Logitech Mouseman Wheel, although other PS/2 mice work equally well
Every KVM switch is different however, and some properly save signals
and restore, others do not. In some cases it is possible to work
around with software/drivers - if direct physical access to the
exact same KVM switch and mouse is available to a developer. In
other cases it is not possible to work around in software, or may
require the KVM vendor to provide patches to enhance a driver to
workaround problems with their KVM hardware.
This problem isn't as prevalent in Microsoft Windows as it is in
Linux, as many people have pointed out in other bugs. The reason
the problem does not occur in Windows as much as it does in Linux
and other OS's, is because the KVM vendor goes out of their way to
ensure Microsoft and other hardware vendors have the proper
information to make their input devices work with the particular
KVM vendor's KVMs.
If you can debug the kernel driver, and provide a data dump of the
raw protocol stream coming from the mouse, it may be possible to
get the kernel driver to detect an out of sync stream perhaps and
reset the hardware. If that is not possible, I recommend filing
a bug report in the X.Org bugzilla also in case an upstream
X developer has access to your particular hardware, and is able to
investigate and debug the issue, and determine if it is possible
to work around in software.
Hope this helps.
I'm having the same problem using a PS/2 wheel mouse and a Belkin
Omni View SE 4-port switch. I'm using a "stock" FC2 kernel,
currently compiling 2.6.7 to see if this resolves the problem (as it
seems to for some other people).
Isn't there some way to force the mouse to re-synchronize?
Unplugging the mouse cable from the back of the PC and reconnecting
Just an update to my (former) problem.
I was using the stock 2.6.6 FC2 kernel and having the problem
described in this bug note exactly.
Compiled 2.6.7 and the problem is gone. You guys might want to give
it a shot.
The Planet (www.planet.co.uk) KVM-200 switch worked fine with FC1,
but I upgraded my system to FC2 and have the same mouse problem
(erratic control in X, and same sync error in the console).
I am using the stock: 2.6.7-1.494.2.2smp #1 SMP Tue Aug 3 09:59:49 EDT
2004 i686 i686 i386 GNU/Linux
With a Belkin 4 port KVM.
The new kernel did not fix the problem. If I unplug my mouse from the
KVM and plug it back in, it works again. No fun, but better than
I have not patched the firmware on my KVM at all. Have those who have
been able to resolve the issue patched their firmware?
Dupe of bug 111161?
*** This bug has been marked as a duplicate of 111161 ***
I have the same problem with FC3 and a LinkSys 4port KVM
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.