News Group Posts

mouse and KVM switch

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.

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> 

Edward Hooper wrote:

> I have two of the above mentioned machines running OpenServer 5.0.6,
> sharing a keyboard, monitor and mouse using the special pass through
> feature on these servers.  For those that don't know, the xSeries 335
> has two non-standard connectors on the back for KVM (one input, the
> other output) so they can be stacked and use one set of IO devices. 
> Sort of like an internal KVM switch.  The problem I have is when I
> switch from one server to the other, the mouse no longer works
> properly.  It has a jerky motion and does not read the button clicks
> correctly.  As an example, double left button click acts like a single
> right button click, but a single left button click will select the
> object under the cursor (sometimes).
> 
> I had the mouse configured as a 'High Resolution Keyboard Mouse: PS/2
> (wheel)' and switched it to Low, but it didn't change a thing.
> 
> I've tried looking for a BIOS setting to handle headless operations
> for the mouse, but can only find it for the keyboard, video, and
> floppy.

Does this happen every time you switch the internal KVM, or only
sometimes?  What happens if the mouse is already in the bad state, and
you switch the KVM away and back again -- does it get even worse, stay
the same, or go back to normal?

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.

>Bela<

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.