Hello,
I see that Thomas Molina 2.5 problem list no longer carries a KVM and
mouse
issue where it previously had.
If a fix is available I'd love to test it out as I still see strange
behavior
with an Intellimouse and my MasterView CS-104 KVM switch (yep its
old).
With a few trusty printks, it looks like after I switch away & back
into 2.5.44, the mouse is now sending 3 byte packets instead of the 4 it
previously was.
As you can imagine this causes all sorts of havok as the packets are
interpretted completely wrong from there on out. If there is enough
delay between
events, the synchonization logic kicks in and throws the packet out,
since
it thinks the 4th byte is old (where it is really the first byte of the
next
3-byte packet). This generates those pesky "psmouse.c: Lost
synchronization "..
However, much of the time an incorrect 4-byte frame gets interpretted
and
the X going totally haywire.
BTW, serio_rescan() gets the mouse back into a happy 4-byte generating
state.
Best Regards,
Jon Grimm
Jon Grimm <[email protected]> writes:
> If a fix is available I'd love to test it out as I still see strange
> behavior
> with an Intellimouse and my MasterView CS-104 KVM switch (yep its
> old).
>
> With a few trusty printks, it looks like after I switch away & back
> into 2.5.44, the mouse is now sending 3 byte packets instead of the 4 it
> previously was.
I had the same problem also with an MasterView KVM and intellimouse.
They seem to have some problems in the mouse protocol implementation
in the switch.
The mouse can be identified through the KVM as a Intellimouse, but when
actually talking later some bytes get dropped. It actually said on the
wrapping that it should work with Intellimouse, but I think they
lied (or Windows uses some different way to initialise the mouse that
works)
Boot with psmouse_noext, that should fix it. It runs the intellimouse as a
plain PS/2 mouse. You lose the additional mouse buttons and the scroll wheel,
but they never worked through that KVM anyways.
-Andi
Thanks Andi,
The workaround sounds reasonable.
-jon
Andi Kleen wrote:
> Boot with psmouse_noext, that should fix it. It runs the intellimouse as a
> plain PS/2 mouse. You lose the additional mouse buttons and the scroll wheel,
> but they never worked through that KVM anyways.
>
> -Andi
>
On Fri, Oct 25, 2002 at 06:57:24PM -0500, Jon Grimm wrote:
> Hello,
> I see that Thomas Molina 2.5 problem list no longer carries a KVM and
> mouse
> issue where it previously had.
>
> If a fix is available I'd love to test it out as I still see strange
> behavior
> with an Intellimouse and my MasterView CS-104 KVM switch (yep its
> old).
>
> With a few trusty printks, it looks like after I switch away & back
> into 2.5.44, the mouse is now sending 3 byte packets instead of the 4 it
> previously was.
>
> As you can imagine this causes all sorts of havok as the packets are
> interpretted completely wrong from there on out. If there is enough
> delay between
> events, the synchonization logic kicks in and throws the packet out,
> since
> it thinks the 4th byte is old (where it is really the first byte of the
> next
> 3-byte packet). This generates those pesky "psmouse.c: Lost
> synchronization "..
> However, much of the time an incorrect 4-byte frame gets interpretted
> and
> the X going totally haywire.
>
> BTW, serio_rescan() gets the mouse back into a happy 4-byte generating
> state.
The workaround is to use "psmouse_noext" command line parameter in case
you use a KVM switch that cannot properly handle the extended protocols.
--
Vojtech Pavlik
SuSE Labs
On Fri, Oct 25, 2002 at 06:57:24PM -0500, Jon Grimm wrote:
> Hello,
> I see that Thomas Molina 2.5 problem list no longer carries a KVM and
> mouse
> issue where it previously had.
>
> If a fix is available I'd love to test it out as I still see strange
> behavior
> with an Intellimouse and my MasterView CS-104 KVM switch (yep its
> old).
>
> With a few trusty printks, it looks like after I switch away & back
> into 2.5.44, the mouse is now sending 3 byte packets instead of the 4 it
> previously was.
>
> As you can imagine this causes all sorts of havok as the packets are
> interpretted completely wrong from there on out. If there is enough
> delay between
> events, the synchonization logic kicks in and throws the packet out,
> since
> it thinks the 4th byte is old (where it is really the first byte of the
> next
> 3-byte packet). This generates those pesky "psmouse.c: Lost
> synchronization "..
> However, much of the time an incorrect 4-byte frame gets interpretted
> and
> the X going totally haywire.
>
> BTW, serio_rescan() gets the mouse back into a happy 4-byte generating
> state.
Use the psmouse_noext option.
--
Vojtech Pavlik
SuSE Labs