Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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.
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:
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 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.
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).
Last edited by RajuVarghese; 01-10-2004 at 01:26 AM.
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.