> 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 y 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.