Re: Belkin KVM erratic mouse Windows Linux

Hi S W,

You're writing to the wrong list.  The forum is to discuss community 
issues, not to discuss helping each other with XFree86 technical support 
(the regular Xfree86 list fulfills that purpose).  If you wish to 
respond to this message, please do so to me individually and not to this 
list.  Note that the list will change the "Reply-To" field of the 
message, so you will have to correct the "To" line of your reply yourself.

I saw a post on the Red Hat Bugzilla about this, they said that they 
weren't going to fix it.  However, there might be information there that 
you might find helpful.  The bug was listed for GPM and not XFree86, and 
it was for Fedora Core 1, not Red Hat Linux 9. However, they claim that 
it is a kernel issue and is not really a problem with the Linux kernel, 
but a problem with certain Belkin KVMs.
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115870>

You might also want to keep in mind this project, if you do not wish to 
upgrade to Fedora Core any time soon:
<http://www.fedoralegacy.org/>
They issue updates using Yum and Apt.  I believe (but am not certain 
about Red Hat Linux 9) Up2date's configuration can be tweaked to check 
and update through Yum and Apt servers (pick one or the other, though).

Peace,
William

S W wrote:
> 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.)