Bug 115870 - Use of KVM requires GPM kill/restart
Use of KVM requires GPM kill/restart
Product: Fedora
Classification: Fedora
Component: gpm (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-02-16 13:54 EST by Jack Aboutboul
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-20 17:49:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jack Aboutboul 2004-02-16 13:54:59 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):

How reproducible:

Steps to Reproduce:
1. setup a Belkin SoHo F1DS104T
2. boot up
3. switch to terminal and try to move the mouse
Actual results:
As described above

Expected results:
Move should move as usual

Additional info:
None. I would have tried to patch but I have no idea on anything mouse
Comment 1 Craig Emery 2004-02-20 10:45:09 EST
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
  InputDevice /dev/input/mice
just fine.

I've got the same settings in FC2 test1 but moving the mouse produces
randon *huge* jumps & mouse clicks. :'(
Comment 2 Craig Emery 2004-02-20 11:05:48 EST
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. :-(
Comment 3 Jack Aboutboul 2004-02-20 11:23:42 EST
    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
for now.
Comment 4 Eido Inoue 2004-02-20 15:28:10 EST
*** Bug 108139 has been marked as a duplicate of this bug. ***
Comment 5 Eido Inoue 2004-02-20 17:49:27 EST
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.
Comment 6 Craig Emery 2004-02-21 13:39:59 EST
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.
Comment 7 Jack Aboutboul 2004-02-22 09:12:17 EST
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!!
Comment 8 Craig Emery 2004-02-22 13:37:05 EST
I think this bug is a duplicate of bug #111161
That bug was opened on 2003-11-28 :-(
Comment 9 Steve Egbert 2004-05-27 19:30:10 EDT
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
> XFree86.
> 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
> transparently.
> 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.)
Comment 10 Chris Marshall 2005-03-02 19:08:35 EST
I have Belkin Omni View SE 4 Port F1D104 and I get this behavior
listed above ... my situation is broken.

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