APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Linux loses mouse on kvm switch; keyboard
© December 2004 Tony Lawrence

KVM switches are great, letting you share one keyboard, monitor and mouse with multiple computers. Unfortunately, mouse drivers seem to be very sensitive and sometimes you'll lose the mouse when you switch. This isn't just a SCO problem; I've seen it on NT too.

The mouse gets "lost" - stops working on one or more of the attached systems. Sometimes you can fix it by getting the screen to refresh on the system with the "dead" mouse, but sometimes nothing but a complete shutdown and reboot will restore the mouse. On Linux/SCO systems try switching away with CTRL-ALT-F1 and then back (CTRL-ALT-F2 on SCO, usually CTRL-ALT-F7 or F8 on Linux).

Some motherboards just won't work with some KVM switches at all. That's probably a matter of power levels rather than anything else, but it can be very annoying. I've often just used separate mice for certain systems rather than fight with it. A higher quality (more expensive) KVM may solve the problem for you, and even just a better grade of KVM cables can sometimes help.

The KVM switch may fail in this way if power is lost: your systems reboot, but the mouse (and maybe other things) don't work. Again, better KVM's have features to prevent this, and a UPS is a better idea anyway..

Here's an old newsgroup post suggesting some debugging on SCO Unix (it didn't help, though).

From: Bela Lubkin <belal@sco.com>
Subject: Re: Mouse issues on IBM @server xSeries 335 using OSR5.0.6
Date: Tue, 22 Jul 2003 00:13:38 GMT
References: <2dc3b402.0307211142.554c8439@posting.google.com> 

Try flipping away, flipping back, not touching the mouse, flipping away,
flipping back, _then_ try the mouse.  Try this with increasing numbers
of back-and-forth flips before you touch the mouse; up to a total of 4.
I am not suggesting these as workarounds, but probes to try to
understand the problem.

What I'm trying to probe is: the keyboard mouse driver expects to see
data from the keyboard mouse in a certain sequence.  It expects a packet
of 3 or 4 bytes (depending on whether it's a non-wheel or wheel mouse).
I'm imagining what would happen if, during the KVM flip, the driver saw
a single byte of garbage.  It might think it was the first byte of a
packet, after which it would be off by one in interpreting packets.  If
each flip produces one garbage byte, flipping 3 or 4 times might get you
back in sync.

There's a problem with this theory: the driver attempts to detect this
condition by rejecting additional bytes of a mouse packet if too much
time has elapsed (defined as 1/4 second).  This defensive check should
prevent the above scenario.  But maybe it doesn't quite work right.

To enhance your testing, you can turn on a keyboard mouse driver debug
flag.  The flag is `kbm_noisy' and the easiest thing is to turn it on in
your live kernel.  Do this:

  # /etc/scodb -w
  scodb> kbm_noisy=1
  scodb> q

The change will persist until you reboot (or change it back to 0 in the
same manner).  I would like to know whether you get any "kbmintr"
warnings with it turned on, when the mouse is in the bad state.

You can also set a second variable, `kbm_dbg', to values of 1 or 2.
Setting it to 1 causes it to print information on what it's sending up
to the mouse reader; 2 causes it to additionally print the actual mouse
bytes as they are received.  0 turns it off.  This output is extremely
verbose for practical purposes, but might be helpful in understanding
your problem.

All of the output produced by these two debug variables appears on the
console.  Under X, it will appear in an "Error" window.  You will
probably find it easier to decipher behavior on a text multiscreen.  In
particular, set `kbm_dbg=2' and flip back and forth, see if the act of
flipping is producing any mouse bytes.


Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Linux and SCO Unix loses mouse on kvm switch ––>Re: kvm switch mousetrouble

1 comment

Inexpensive and informative Apple related e-books:

Take Control of Automating Your Mac

Take Control of OS X Server

Take Control of Preview

iOS 10: A Take Control Crash Course

Take Control of Numbers

More Articles by © Tony Lawrence

Sun Nov 29 05:50:46 2009: 7684   anonymous

I just suffered the same thing: PS/2 mouse on Linux went dead (I was recabling the KVM, but sometimes it's just from the cable coming loose). The way around it: plug in a USB mouse. It'll be instantly recognized, so use that 'till you reboot and regain use of the PS/2 mouse/trackball/pointing-device.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

There is no reason anyone would want a computer in their home. (Ken Olson, president, chairman and founder of DEC)

Linux posts

Troubleshooting posts

This post tagged:




Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode