Red Hat Bugzilla – Bug 115870
Use of KVM requires GPM kill/restart
Last modified: 2007-11-30 17:10:36 EST
Description of problem:
When using a Belkin SoHo F1DS104T KVM switch, gpm must be killed and
restarted in order to get the mouse to work on the console. If gpm is
not killed, the cursor will always show up in the upper right hand
corner and any attempt to move the cursor just results in the login
screen being echoed over and over again. This was tested with
multiple mice, including trackball, standard ball mouse and optical.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. setup a Belkin SoHo F1DS104T
2. boot up
3. switch to terminal and try to move the mouse
As described above
Move should move as usual
None. I would have tried to patch but I have no idea on anything mouse
I've got a Belkin F1DB104P 4x KVM.
Machine 1: RedHat 9
Machine 2: Windows 2000
Machine 3: Fedora Core 2 Test 1 (kernel 2.6.1-1.65)
I tried updating to kernel 2.6.1-1.85 but got no mouse at all. (unable
to open /dev/psaux)
Even if I kill gpm and restart it I still cannot use the same gpm and
X11 pointer/input device as I do under RH9.
I've got a cordless logitec trackman wheel. It's a PS/2 mouse.
Under RH9 I can use:
gpm -t imps2 -m /dev/psaux
I've got the same settings in FC2 test1 but moving the mouse produces
randon *huge* jumps & mouse clicks. :'(
Moving to kernel 2.6.2-1.87 and making /dev/psaux a link to
/dev/input/mice (as per bug #116179) didn't help things.
If I boot w/ the KVM on my Fedora box I can use the mouse.
But after switching away (to my RH9 box) if I switch back I'm hosed. :-(
Ok. Heres a solution for your mouse not being detected as
/dev/psaux or /dev/mouse. change your corepointer to "/dev/input/mice"
in your XF86Config and then modprobe "evdev" . That should have you
up and running.
I still have some other issues with the kvm, not only at the
console but in X as well. First off, I have FC1 on the first port of
the KVM and a windows xp machine on the second port. If I boot the
FC1 machine alone, when rhgb or X/gdm starts, I can use the mouse for
about a second before it dies. The red light from the optics goes
dead. However, if I have the windows machine on, and the boot the FC1
machine, I don't have this problem. I can also shutdown the windows
machine, (without switching to it, just pressing the power button to
initialize shutdown,) and my mouse will work fine.
Additionally, if i switch to another machine on the kvm and back,
the mouse is hosed. I'm not sure if my first problem (rhgb/X whatever)
is a power problem or not, since I'm using an old asus board on my FC1
machine and when the other machine is on it works. Anyway, thats all
*** Bug 108139 has been marked as a duplicate of this bug. ***
This seems to be very hardware specific-- Red Hat developers find that
some of the Belkins just simply don't work (the one's with the plastic
cases)-- not just with gpm... but with X period. So the KVM problem is
not a problem directly related to gpm... but mouse interaction as a whole.
FWIW, the Belkin OmniPort 4 point (metal box, model #F1D09U) does work
just great with various Linux boxen and Windows.
Either way, the fix is not for gpm, but for the actual way the kernel
device for the mouse works.
Is there at least another bug I could track (regarding mouse handling
by the kernel)?
Is this a 2.6 specific issue?
I'm using RH 9 w/ this KVM with no issues at all.
This bug (gpm or otherwise) is *completely* stopping me from using
Fedora. As FC2 test1 is a testing release not recommended for
production machines, I see having it on another machine accessable via
a KVM as an obvious way of testing it & giving constructive feedback.
Hey, this is definitely a kernel bug now. I just rolled my own 2.4.25
and it works fine, I'm not having any issues aside from when I change
back and forth from another machine where the mouse will flip out. So
something is not on/enabled in the RH kernel, I'll take a look at the
spec files later and try to determine what it is. I'm also gonna try
my own 2.4.25 with preemption to see if that works.
P.S. Hey bfox!!
I think this bug is a duplicate of bug #111161
That bug was opened on 2003-11-28 :-(
I sent this over to XFree86 this excerpt of the similar problem...
S W wrote:
> I've searched high and low... Got a Belkin E-series
> KVM, RedHat 9.0, Windows2KPro and a lowly wheel
> Intellimouse 1.3A PS/2 that behaves erratically only
> under RedHat 9.0 (which is XFree 4.3.0).
> When ever I switched from Linux to Windows, KVM spews
> some weird characters toward the Linux mouse driver
> and screws the driver sync up royally to an unknown
> IMPS protocol state. I suspect Windows IMPS/2 has a
> graceful recovery mechansim (as it always works) and
> quite possibly a different rate and resolution problem
> between Xfree 4.3.0 and WIndows2KPro using Standard
> PS/2 mouse driver.
> All XFree86 settings from "auto", "IMPS/2", "PS/2"
> have different problems:
> "PS/2" is the best solution but disables the wheel
> mouse under LInux only. Not an acceptable solution
> "IMPS/2" is the desirable solution but whenever one
> goes back to Linux/RedHat via KVM, the mouse driver
> behaves erractically.
> "AUTO" is more like "IMPS/2" at bootup and more like
> "PS/2" at CTRL-ALT-BKSP.
> What we need is a IMPS/2 resynch routine and/or and
> better clocking/receiver of the psaux port from
> I found this over at one of the NetBSD with regard to
> "8elkin" KVM.
> The pmsi driver cannot cope with a KVM switch which
> may occasionally forget about scroll wheels.
> Furthermore, it is an offense against elegant design
> for the pmsi driver to be nearly identical to the
> standard pms driver, except that it does some weird
> magic, and it doesn't know about 5-button mice.
> Proposed, that psm.c should be revised to process
> multiple types of mice, and handle the protocol
> Secondly, once you've done this, the annoying tendency
> of a certain KVM switch, made by a vendor who shall
> rename nameless, but whose name would rhyme with
> "pelkin" if that were a word, to reset the mouse
> silently into plain-old psm mode creates problems.
> The solution is to check each non-initial byte of a
> packet for delay. The normal delay between PS/2
> packet bytes seems to be around 1700us, plus or minus
> thirty. An occasional byte may take up to 5000us to
> arrive. A delay of, say, 30000us reliably indicates
> that the new byte is part of a different packet.
> Thus, if the driver isn't expecting a new packet, and
> sees a long delay, it now resets the mouse, throwing
> the packet out in the process.
> Buy a KVM switch.
> (This also implies throwing out psm_intelli.c, which
> we don't need.)
I have Belkin Omni View SE 4 Port F1D104 and I get this behavior
listed above ... my situation is broken.