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
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
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
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.
I set the debug flags as you mentioned (kbm_noisy=1 & kbm_dbg=2) with
the following results:
1) Switching between servers using the built in KVM switch does not
generate a signal that the mouse driver is picking up.
2) After a time, the debug messages stop displaying on the console,
but the mouse continues to function (sort of: same problem as before).
3) Switching rapidly between servers does not change behavior of the
mouse. (I tried doing it one, two, three and four times...)
4) Switch between virtual consoles on the same server unsticks the
debug output (see #2). But not all of the time...
And now I see that the graphical desktop (on tty02) has stopped
functioning. I had to run 'scologin stop' and 'scologin start' to
bring it back.
Maybe I'm using the wrong driver here. Is there a special driver for
the IBM series servers that is needed? When I looked up the server on
the SCO website to see if it was certified, the page with all of the
information showed which oss packages to load (already done) but
didn't mention a special mouse driver that was required. Just as an
experiment I will rebout the server that has the mouse plugged in
directly and leave it there, to see if the mouse goes south all on
Thanks for the help so far!