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): 1.20.1-38 How reproducible: Always 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 related.
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 and 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. :'(
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 for now.
*** 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 > 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. > > >>How-To-Repeat: > > Buy a KVM switch. > > >>Fix: > > (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.