Bug 4469

Summary:	Sync problems with wheel mouse on ps2 port
Product:	Drivers	Reporter:	Tom Watson (tsw)
Component:	Input Devices	Assignee:	Dmitry Torokhov (dmitry.torokhov)
Status:	REJECTED DUPLICATE
Severity:	low	CC:	vojtech
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.11.7	Subsystem:
Regression:	---	Bisected commit-id:

Description Tom Watson 2005-04-10 21:07:41 UTC

Distribution: Direct download from kernel.org
Hardware Environment:VIA EPIA motherboard (Neiahmia[sp?] processor)
Software Environment:Xorg X11 server
Problem Description:I recently converted to the 2.6 kernel, obtaining the latest
from kernel.org.  I have a nice 4 port KVM (active) switch to move to/from
various machines.  When I switch machines to and fro, the wheel mouse loses sync
(I'm not exactly sure how, but I believe the KVM switch has a bit to do with
it).  When I was using the 2.4 kernel (2.4.20 from Red Hat), I was able to
re-sync by switching to a character console (keyboard ctrl-alt-F1 for example)
then switching back to the X server (alt-F7).  On the 2.6 kernel I'm using this
doesn't work any more.  I believe this is totally related to the fact I have a
wheel mouse, as when I did work (on the 2.4 kernel) without the wheel mouse I
didn't have this problem.  While I appreciate that this might not be 'easy' to
re-sync the mouse "automagically", if a keyboard sequence (pick one, I'm easy)
would re-sync/reset the mouse I would consider it "solved".

Steps to reproduce:
I can easily do this with my KVM switch (an older model that doesn't know about
wheel mice).  I just cycle around, and the mouse pointer goes haywire.  I also
have a "passive" (no electronics) KVM switch, but it doesn't exhibit this
beheaveor[sp?].  A wheel mouse if definitevely required to do this.  If a patch
needs to be entered to get the data dumped, I should be more than able to do it.

Comment 1 Tom Watson 2005-12-23 14:37:37 UTC

More info (from my current experience):
It seems that the KVM switch I'm using does a reset to the mouse (there are a
bunch of bytes you send to the mouse to do that), and this reset puts the
mouse in "non scroll" mode.  Given that the upstream consumer of the mouse data
wants the data in "scroll mode", it consumes the data in that mode.  This 
causes all sorts of things like clicks in the (0,0) location and the like.  
The 2.4 kernels when switching to/from various virtual consoles sent the 
proper mouse commands if the mode on the mouse was different.  I believe (I 
have no real data) that the mouse stayed in the same mode from a text console 
to the graphics console, and as a result the mouse re-definition commands were 
not sent (my loss!!).  If there was some way (insert prayer words to proper 
diety here) just to have a key sequence to reset the mouse to the proper mode 
currently in use, I would consider the problem solved.  At the moment it seems 
that the common usage is ALT-F1 thru ALT-F6 specify text consoles (I assume 
this is configurable).  The key combination ALT-F7 selects the graphics 
console (X window).  Maybe the last combination (ALT-F12) could be set aside 
to re-configure the mouse.

Just random thoughts.  Thanks for listening.

Comment 2 Dmitry Torokhov 2005-12-23 14:51:21 UTC

I would appreciate if you could test the latest (resync-after-idle-v3) patch in 
2802. Thanks! 

*** This bug has been marked as a duplicate of 2082 ***