ps/2 mouse problem with KVM switch

ps/2 mouse problem with KVM switch

[Marko Macek]

Hello!

Kernel 2.6.2, XFree86 4.3.0

I am using a Logitech MouseMan 2xOptical mouse connected trough a KVM 
switch.

By default the mouse is detected as "ImExPS/2 Logitech Explorer Mouse".

The problem is that the mouse doesn't work. It is too slow and no mouse 
clicks work. If I move it very fast I sometimes get a random click event.

I specify psmouse.proto=bare mouse works OK, but not the wheel :(
(I have seen at least one "lost synchronization").

Specifying psmouse.proto=imps or exps doesn't help.

Without the KVM switch all is ok (as much as I tested under 2.6.0).

Under 2.4 mouse works perfectly, wheel and all.

I am using /dev/input/mice under XF86 (kernel does complain about X 
using direct hardware for keyboard and gives a bunch of errors).

GPM shows the same behavior if I run it (I'm not using it).

What else can I do?

Regards,
MArk

RE: ps/2 mouse problem with KVM switch

[Robert White]

Note that the KVM Switch (typically) implements an intermediate "device" for
the mouse so that when you are switched away to the other machine, the first
machine is still "talking to something".

This has the less-than-desireable effect of causing the mouse device "inside
the switch" to act as a largest-common-denominator.  Consequently many of
the special features and peculiarities of your real device may not be
accessible to your computer.

A particular, and bette-documented, example of this can probably be found by
trying to hook up a "new-fangled" keyboard (with the media control key
cluster across the top and such) to your windows box.  When the keyboard
drivers cannot find the special buttons and you call the KVM switch vendor
they will promptly tell you about how all those hot extra buttons are not
supported with their product, have a nice day, good-bye... 8-)

The same things go four your mouse, but are not as well documented and
accessible to the KFM help desk weasels.

You should find that if you select a "much more generic" mouse configuration
"everything works fine".

Some newer windows drivers "look past" the switch and activate the mouse
features anyway.

Regardless, if your "other" computer is initializing the mouse through
voodoo and dark magic to increase the reporting (baud?) rate and such, when
you toggle to the Linux box you will see all sorts of unhappiness.  The
inverse is also true, if the windows driver is expecting
fast-and-feature-full and the side trip to Linux has set things back to
mundane, the return to Windows will be "exciting"

Ibid for switching between two differently-abled Linux boxes, or two windows
boxes with different driver revisions and settings.

It got so bad for me in a couple of places that I have re-mastered the art
of the keyboard shortcut and don't have my mouse plugged into the KVM switch
at all, and only mouse when using my "prime" environment.  (for emergency
mousing on "the other box" I have an old mouse plugged in and set aside.)

More often than not I just hook up one box with an near-optimal
configuration and then use VNC from that box to reach out to all the others.

A/The KVM switched environment should be considered "imperfect" for almost
all other-than-stock uses.


(My optimal configuration that saves heartache)

2-Port plasma flat panel
  DVI port connected to my primary use machine
  VGA port connected to my KVM

Keyboard (no special buttions 8-) connected to KVM

Mouse connected to Primary Machine via USB

KVM keyboard ports connected to all machines

KVM mouse ports connected to all machines *EXCEPT* primary

Stand-by mouse connected to KVM

Normally I am use the directly connected mouse and monitor.

When I switch to any other machine via the KVM the VGA port comes live on
the monitor and I touch the "other input source" button on the monitor too.
As long as I am visiting the other machines I stay VGA.  When I switch back
to the primary the VGA feed goes dead and the monitor automatically switches
back to DVI.

So now It takes two button presses to switch away, but only one to home
back.

---
Less than optimal, yes, but technologically sound.  Since there is no "soft
reset" behavior provided by the PS/2 standard, let alone any way for the KVM
switch to signal the driver that such logic needs to be invoked in software,
the real truth of the issue is that this is a limitation inherent in the
design of the PS/2 interface and any solution other than
greatest-common-denominator will be unstable.

It would have been better if the PS/2 (and keyboard) interface were designed
with hot-plugability in mind and the KVM switch did nothing but detach the
devices so that a "switch to" even caused the software to rediscover the
device and reset the parameters.  The thing was that part of the core
purpose of the KVM today was designed to prevent the old "keyboard not
found, press F1 to continue booting" nonsense... Thank You Pane/Webber. 8-)

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Marko Macek
Sent: Sunday, February 08, 2004 1:35 AM
To: vojtech@suse.cz
Cc: linux-kernel@vger.kernel.org
Subject: ps/2 mouse problem with KVM switch

Hello!

Kernel 2.6.2, XFree86 4.3.0

I am using a Logitech MouseMan 2xOptical mouse connected trough a KVM 
switch.

By default the mouse is detected as "ImExPS/2 Logitech Explorer Mouse".

The problem is that the mouse doesn't work. It is too slow and no mouse 
clicks work. If I move it very fast I sometimes get a random click event.

I specify psmouse.proto=bare mouse works OK, but not the wheel :(
(I have seen at least one "lost synchronization").

Specifying psmouse.proto=imps or exps doesn't help.

Without the KVM switch all is ok (as much as I tested under 2.6.0).

Under 2.4 mouse works perfectly, wheel and all.

I am using /dev/input/mice under XF86 (kernel does complain about X 
using direct hardware for keyboard and gives a bunch of errors).

GPM shows the same behavior if I run it (I'm not using it).

What else can I do?

Regards,
MArk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ps/2 mouse problem with KVM switch

[Vojtech Pavlik]

On Thu, Feb 12, 2004 at 02:29:24PM -0800, Robert White wrote:

> Less than optimal, yes, but technologically sound.  Since there is no "soft
> reset" behavior provided by the PS/2 standard, let alone any way for the KVM
> switch to signal the driver that such logic needs to be invoked in software,
> the real truth of the issue is that this is a limitation inherent in the
> design of the PS/2 interface and any solution other than
> greatest-common-denominator will be unstable.
> 
> It would have been better if the PS/2 (and keyboard) interface were designed
> with hot-plugability in mind and the KVM switch did nothing but detach the
> devices so that a "switch to" even caused the software to rediscover the
> device and reset the parameters.  The thing was that part of the core
> purpose of the KVM today was designed to prevent the old "keyboard not
> found, press F1 to continue booting" nonsense... Thank You Pane/Webber. 8-)
> 
> Rob.
> 

Sadly enough, there is a soft reset command in the PS/2 protocol, and
the PS/2 interface is designed for hotplug, and because of that Linux
2.6 can easily handle hotplugging of both PS/2 keyboards and mice,
including type detection, etc, BUT the KVM switches don't use that,
because Windows historically doesn't support unplugging a PS/2 mouse.

The most ugly part of the KVM switch in this play is that while the KVM
switch usually implements a virtual mouse for each of the machines, it
lets them all talk to the real one, and if they have different ideas
about what mode the mouse should be set to, well, then there goes the
road to madness.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: ps/2 mouse problem with KVM switch

[Marko Macek]

Vojtech Pavlik wrote:

> Sadly enough, there is a soft reset command in the PS/2 protocol, and
> the PS/2 interface is designed for hotplug, and because of that Linux
> 2.6 can easily handle hotplugging of both PS/2 keyboards and mice,
> including type detection, etc, BUT the KVM switches don't use that,
> because Windows historically doesn't support unplugging a PS/2 mouse.

If the mouse gets into confusing state, I can "replug" it into the KVM 
switch (while in Windows) and it works fine after that. I have also 
noticed that when Windows is doing "resume" I must not switch away 
before it is if I want my mouse to work (otherwise I will need to replug).

For Linux, I also need to switch from X to console and back when the 
mouse is "confused".

With 2.4 I repeat the the 2 steps described above my mouse works (incl 
wheel) on both machines after that.

> The most ugly part of the KVM switch in this play is that while the KVM
> switch usually implements a virtual mouse for each of the machines, it
> lets them all talk to the real one, and if they have different ideas
> about what mode the mouse should be set to, well, then there goes the
> road to madness.

I guess I need to figure out how to force both machines to initialize 
the mouse in the same way then...

Regards,
Mark

Re: ps/2 mouse problem with KVM switch

[Marko Macek]

Robert White wrote:
> Note that the KVM Switch (typically) implements an intermediate "device" for
> the mouse so that when you are switched away to the other machine, the first
> machine is still "talking to something".
> 
> This has the less-than-desireable effect of causing the mouse device "inside
> the switch" to act as a largest-common-denominator.  Consequently many of
> the special features and peculiarities of your real device may not be
> accessible to your computer.

Well, under 2.4 they all work, probably because the settings for both 
systems are the same.

> A particular, and bette-documented, example of this can probably be found by
> trying to hook up a "new-fangled" keyboard (with the media control key
> cluster across the top and such) to your windows box.  When the keyboard
> drivers cannot find the special buttons and you call the KVM switch vendor
> they will promptly tell you about how all those hot extra buttons are not
> supported with their product, have a nice day, good-bye... 8-)

I have a Microsoft internet keyboard and the keys all work. I guess MS 
is big enough to be supported. (not that I use any of the keys). I 
haven't tried others.

> The same things go four your mouse, but are not as well documented and
> accessible to the KFM help desk weasels.
> 
> You should find that if you select a "much more generic" mouse configuration
> "everything works fine".

Yes, "bare" works. But I want my wheel to work.

> Some newer windows drivers "look past" the switch and activate the mouse
> features anyway.
> 
> Regardless, if your "other" computer is initializing the mouse through
> voodoo and dark magic to increase the reporting (baud?) rate and such, when
> you toggle to the Linux box you will see all sorts of unhappiness.  The
> inverse is also true, if the windows driver is expecting
> fast-and-feature-full and the side trip to Linux has set things back to
> mundane, the return to Windows will be "exciting"

I can see this would be a problem. I just haven't figured out the right 
rate, ... settings yet.
> 
> (My optimal configuration that saves heartache)
> 
> 2-Port plasma flat panel
>   DVI port connected to my primary use machine
>   VGA port connected to my KVM

I plan to to that when I upgrade my monitor. My current one doesn't have 
2 inputs. I'd still prefer one mouse and keyboard.


Regards,
Mark