Bug 123273 - Erratic mouse behaviour when using KVM switch to return to Fedora box
Erratic mouse behaviour when using KVM switch to return to Fedora box
Status: CLOSED DUPLICATE of bug 111161
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-15 07:46 EDT by Chris M
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:03:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris M 2004-05-15 07:46:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
The mouse works fine normally and is set to the following in the
XF86Config file:

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):


How reproducible:
Always

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

Additional info:

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
XF68Config file.
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
workaround.
Comment 1 Chris M 2004-05-18 14:27:16 EDT
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 
mouse drivers."

As the psaux driver used to work with the "MouseManPlusPS/2" 
protocol, is it possible to bring that back?
Comment 2 Arnaud MOURONVAL 2004-06-01 17:48:06 EDT
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.
Comment 3 Ben Ryan 2004-06-07 20:14:33 EDT
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] 
bytes away.".
Comment 4 Sofoklis 2004-06-10 15:26:56 EDT
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.
Comment 5 David R. Van Sandt 2004-06-19 01:49:58 EDT
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.
Comment 6 Chris M 2004-06-19 07:49:22 EDT
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.
Comment 7 Tom Diehl 2004-06-20 16:04:51 EDT
Keep in mind that, if you have a wheel mouse the wheel will not work.
Comment 8 Mike A. Harris 2004-06-23 08:35:55 EDT
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
>problem.

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
during testing.

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.



Comment 9 jon 2004-07-07 11:49:49 EDT
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 
doesn't help.  
Comment 10 jon 2004-07-08 13:59:40 EDT
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.
Comment 11 Rui 2004-08-05 06:31:23 EDT
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).

 
Comment 12 Andrew B. Lundgren 2004-08-18 16:39:43 EDT
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
rebooting.

I have not patched the firmware on my KVM at all.  Have those who have
been able to resolve the issue patched their firmware?
Comment 13 Brian "netdragon" Bober 2004-09-07 11:47:55 EDT
Dupe of bug 111161?
Comment 14 Mike A. Harris 2004-09-21 05:52:16 EDT

*** This bug has been marked as a duplicate of 111161 ***
Comment 15 Les Dunaway 2004-12-28 13:47:47 EST
I have the same problem with FC3 and a LinkSys 4port KVM
Comment 16 Red Hat Bugzilla 2006-02-21 14:03:14 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.