2.5.44: Still has KVM + Mouse issues
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
Quoted 27 lines · Jon Grimm
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.
Quoted 2 lines
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 27 lines · Jon Grimm
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.
Quoted 2 lines
BTW,
serio_rescan()gets the mouse back into a happy 4-byte generating state.
Use the psmouse_noext option.
Signature · 2 lines
Vojtech Pavlik SuSE Labs