I'm not sure whether to report this upstream or to you. I guess its best if you have a look at it first so as to determine whether this is Fedora-specific or not. Description of problem: http://bugs.xfree86.org/show_bug.cgi?id=34 When you disconnect the mouse, then reconnect it... For instance when using an electronic KVM switch that simulates a PS/2 mouse but not an Intellimouse, you get permanent erratic mouse behavior. The desynch was detected, but it still seems unable to re-synchronize. May 25 20:27:27 localhost gpm[2440]: imps2: Auto-detected intellimouse PS/2 May 25 20:27:35 localhost kernel: psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. May 25 20:27:46 localhost kernel: psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. After this, you have to reboot. That means you cannot use, for instance, a Belkin SOHO2 PS/2 KVM switch with an Intellimouse. Version-Release number of selected component (if applicable): 2.6.5-1.358 Are there any workarounds?
if (psmouse->state == PSMOUSE_ACTIVATED && psmouse->pktcnt && time_after(jiffies, psmouse->last + HZ/2)) { printk(KERN_WARNING "psmouse.c: %s at %s lost synchronization, throwing %d bytes away.\n", psmouse->name, psmouse->phys, psmouse->pktcnt); psmouse->pktcnt = 0; } Should this part do a full mouse reset if the mouse is intellimouse? I think that's what Windows does.
I see this problem using an optical Intellimouse and an ICS-124 KVM. Workaround for me is to add 'psmouse.proto=bare' to the kernel options when booting (or in grub.conf).
FYI - I had the same issue w/ a Belkin Optical mouse setup as a Generic Wheel mouse. Adding the "'.proto=bare' to the kernel options when booting" seems to have resolved the issue. I had this same issue with RH 9 and I have to always run mouse-config -noui to get it back.
Dupe of bug 111161?
*** This bug has been marked as a duplicate of 111161 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.