KVM mouse glitch

For those of you with the belkin 4-port KVM I have this information.

I am in a High Performance computing program at a local college. We are in the process of building a 4 node cluster. The head node has RedHat 9, the other Redhat 7.2. When switching off of 9 and back again causes the mouse to lose its mind. The fix is, go to belkins website, and navigate to the support section, then download manuals and drivers. There is a section labeled General FaQs, right under it GENERAL KVM TROUBLESHOOTING. There you should find the solution. There is a known issue with linux. Followed the procedure, and now switched between nodes is no problem.

http://web.belkin.com/support/faq_qa.asp?pid=190&cid=


Hope this helps

I have talked to a few other Linux Gurus and they all said the same thing.

"I have (1) mouse for my Linux Box and (1) mouse for all my other boxes using the KVM."

They said that this problem has always been there.

This is a pretty sad resolution. But I did it to move on.

"If you support it they will come" is probably the best slogon I have ever heard.

I did not see overzexezd24's reply post on the procedure from Belkin.

I will try the suggested procedure and update on the outcome.

I might be a little late, but guess what I am having the same problem at work - work around 1) when switching to linux try to switch to a different virtual console and back to X - works for me; 2) after struggling with all this madness on Belkin OmniView 4 port PS/2 switch I've installed VNC server on windows machine and VNC viewer on linux machine, put aside the KVM switch, and now my windows box is headless, and anyway I am only using it to polute my Netware share with downloads and Lotus Notes (it would be mad cool if I could find a way to connect to Novell Netware drives using TCP/IP untill then I am just dreaming about building a FreeBSD box out of winxp machine).

Yeah, using the belkin, when I switch, I get one free use of the mouse, as soon as I switch to another port then come back the mouse is goofed. To fix the problem I just switch to a different console Alt+F3 seems to be my default, but that's just me, then back to X and the mouse is ok...

I'll look in to the Belkin FAQ though...hopefully it's as promising as it seems.

My KVM switch (a local rebadged product) exhibited the 'erratic mouse' problem whenever my linux machine booted up. To get it to work I had to futz around for half an hour with the Suse control center till it starting working. But, as I rebooted the machine once every blue moon, this was not an issue. But to put an end to it I devoted some time today and I think I have succeeded. I changed the mouse protocol to 'auto' and that seems to have done the job. I rebooted about three times to check this and the problem seems to have gone away for me. This is the extract from my XF86Config on SuSE 9.0:

---
Section "InputDevice"
Driver "mouse"
Identifier "Mouse[1]"
Option "Device" "/dev/mouse"
Option "Name" "Autodetection"
Option "Protocol" "auto"
Option "Vendor" "Sysp"
EndSection
---

The only line I changed was the one with Protocol.

This may have helped with my old linux box ( My mouse wouldn't even work..I guess I could give it a try though :-D ), however, for the problem I experience, with erratic mouse after switching back and forth more than two times, this does not help :-(

I have problem with KVM switch (Belkin) going from Linux to Windows FINE but from Win to Linux - mouse goes crazy!

Does anyone know how to fix this? I'm a Linux newbie.

Linux 9.0 Professional.

Originally posted by RajuVarghese --- ............... Option "Protocol" "auto" ............... --- The only line I changed was the one with Protocol. [/B]

That was exactly what I was needing on my Belkin KVM with SuSe 9 and Redhat 9 attached.

Thanks RajuVarghese!!!!

Thanks for solution.

I have Suse 9.0 and the Belkin KVM everyone uses. My workaround was to change to runlevel 3 before switching. When I go back to Linux everything is good, because there's no X, but when I try to switch to runlevel 5 the desktop doesn't start, only X. I'm sure there's a reason for this, and I was going to research the problem, but this sounds much easier.

If your mouse goofs, there's no need to switch to a different run level, just switch to another pseudo terminal, hit alt+F3, then hit alt+F7 to switch back to your GUI ( some of you will hit alt+F6 ).

Unless one of the options presented help you, that's how to get rid of a glitchy mouse.

Switching virtual consoles does not always work. In fact, it rarely solved the problem for me. Switching run-levels did it but was very inconvenient. I finally solved it by setting the mouse protocol to auto (as described in a previous post).

I changed the mouse protocol to 'auto' too. Works great. I was a little concerned about editing the XF86Config file when it says 'do not edit', but couldn't find a Yast tool for the job.

Perhaps it would help if I explain just what is going on here, so you can best judge how to deal with the problem.

A "standard" PS/2 mouse has only 2 buttons, no wheel, and defaults to 100 samples/second and 4 counts/mm. For any wheelmouse or other exotic pointing device to work, it has to be initialised from sending the "standard" PS/2 protocol to its own enhanced protocol, which is almost always incompatible with ths standard PS/2 protocol. No problems so far - the 2.4 kernel relies on XFree86 or gpm to initialise the mouse, and the 2.6 kernel initialises the mouse itself.

The problem is that when you switch a Belkin KVM, the mouse resets to "standard" PS/2, but this goes undetected under Linux and so the data continues to be read as if it were enhanced data. This manifests itself by the cursor moving eratically round the screen clicking madly as it incorrectly interprets the data sent by the mouse.

Now, what happens exactly depends on which kernel and version of XFree86 you're using:

On 2.4 kernels with older versions of XFree86, when you switch you'll get the erratic behaviour. You'll need to switch to a virtual console and back into XFree86 (CTRL-ALT-F1 then CTRL-ALT-F7 usually for distros with 6 virtual consoles) - this will cause XFree86 to reinitialise the mouse into enhanced mode when you switch back into it, but won't work if you're running gpm.

On 2.4 kernels with more recent versions of XFree86, the mouse will be partly reinitialised when you switch - the enhanced protocol will work, but the sample rate and resolution will be reset back to default, a minor annoyance. Again, you can switch to a virtual console and back to force XFree86 to reinitialise the mouse.

On 2.6 kernels, you'll again get erratic behaviour when you switch. Unlike the 2.4 kernel, switching to and from XFree86 won't help, because the kernel handles the mouse directly. The only solution on a 2.6 kernel is to physically unplug the mouse from the KVM and plug it back in again, which causes the kenel to detect the disconnect and reinitialise the mouse. You could also reboot. Neither is a particularly practical solution.

The only real long term solution other than to go back to using your mouse as a standard 2 button, no wheel mouse is for protocol sanity checks to go into the 2.6 kernel, XFree86 and/or gpm which force a reinitialisation of the mouse into the "expected" protocol and settings if the values of the data fall outside sane limits. Windows seems to already handle this quite well, so it apparently can be done.

These checks were meant to be going into the 2.6 kernel at some point, and indeed already exist in a limited form for touchpad, but unfortunately don't seem to work for the general case yet. At least some kernel developers finally seem to be recognising there is a problem now, though.

So.. in short, assuming your mouse settings are correct, you'll either have to change them to standard PS/2 and lose the wheel and extra button support, or get used to switching consoles or unplugging the mouse.

All of my KVM problems went away when I noticed that the actual mouse I was using was connected to the
KVM through one of those PS/2 (round plug) to USB (rectangle plug) converters.

I found another mouse that didn't need the converter, but still has the wheel and everything works great.

For me the IMPS/2 didn't matter and getting rid of the scroll wheel in XF86Config didn't help but getting that converter out of the way made everything work like magic.

Drake42