I've searched high and low... Got a Belkin E-series KVM, RedHat 9.0, Windows2KPro and a lowly wheel Intellimouse 1.3A PS/2 that behaves erratically only under RedHat 9.0 (which is XFree 4.3.0). When ever I switched from Linux to Windows, KVM spews some weird characters toward the Linux mouse driver and screws the driver sync up royally to an unknown IMPS protocol state. I suspect Windows IMPS/2 has a graceful recovery mechansim (as it always works) and quite possibly a different rate and resolution problem between Xfree 4.3.0 and WIndows2KPro using Standard PS/2 mouse driver. All XFree86 settings from "auto", "IMPS/2", "PS/2" have different problems: "PS/2" is the best solution but disables the wheel mouse under LInux only. Not an acceptable solution "IMPS/2" is the desirable solution but whenever one goes back to Linux/RedHat via KVM, the mouse driver behaves erractically. "AUTO" is more like "IMPS/2" at bootup and more like "PS/2" at CTRL-ALT-BKSP. What we need is a IMPS/2 resynch routine and/or and better clocking/receiver of the psaux port from XFree86. I found this over at one of the NetBSD with regard to "8elkin" KVM. The pmsi driver cannot cope with a KVM switch which may occasionally forget about scroll wheels. Furthermore, it is an offense against elegant design for the pmsi driver to be nearly identical to the standard pms driver, except that it does some weird magic, and it doesn't know about 5-button mice. Proposed, that psm.c should be revised to process multiple types of mice, and handle the protocol transparently. Secondly, once you've done this, the annoying tendency of a certain KVM switch, made by a vendor who shall rename nameless, but whose name would rhyme with "pelkin" if that were a word, to reset the mouse silently into plain-old psm mode creates problems. The solution is to check each non-initial byte of a packet for delay. The normal delay between PS/2 packet bytes seems to be around 1700us, plus or minus thirty. An occasional byte may take up to 5000us to arrive. A delay of, say, 30000us reliably indicates that the new byte is part of a different packet. Thus, if the driver isn't expecting a new packet, and sees a long delay, it now resets the mouse, throwing the packet out in the process. >How-To-Repeat: Buy a KVM switch. >Fix: (This also implies throwing out psm_intelli.c, which we don't need.) __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
