Date: Thu, 16 Aug 2001 11:25:08 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Warner Losh <imp@harmony.village.org> Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach) Message-ID: <200108160225.LAA08355@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Wed, 15 Aug 2001 07:47:06 CST." <200108151347.f7FDl6W23619@harmony.village.org> References: <200108150924.SAA06230@zodiac.mech.utsunomiya-u.ac.jp> <200108151347.f7FDl6W23619@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>: Too complicated? > >I like this idea. It will allow mechanical KVM switches to "work" >better than they do now (which is to say, not much at all). I also >have one KVM switch that hits the out-of-sync problem when its power >fails. Unfortunately, it has a horrible user interface: The power >button and the switch console buttons are next to each other. > >I assume that initializing the mouse is somewhat expensive and >something that you wish to avoid? Yes. Reset and re-initialization involves sending a series of commands to the mouse. It will take time. In addition, after we send the reset command to the mouse, we have to wait until it returns a status code. Loctech's technical document states that it will be between 300 and 500 msec. But, I know, from our users' reports in the past, that some mice take a lot longer time than this before sending the status. Moreover, if we have a KVM between the mouse and the FreeBSD box, there may be additional delay (I also had a report on such KVM). So, the current psm code will wait up to 2 seconds in the worst case. There have been some cases where I had to advise users to set longer wait time via the kernel compile option PSM_RESETDELAY and PSM_MAXWAIT (see the man page for psm(4)) for some mice and KVM. While we are carrying out the reset/initialization sequence, the mouse pointer will be frozen on the screen. The keyboard input may not respond in a timely fasion because the PS/2 mouse and the AT keyboard share the same I/O port. Then, I suspect our user may feel uneasy and think the entire FreeBSD is frozen... What do you think the average user will do in such situation? It is quite likely that s/he will wiggle the mouse (rather frantically?) to see if the mouse is dead, won't he? I am not sure our initialization sequence is robust enough to not be disturbed by this. If disable/enable sequence, which is lot simpler and takes considrably less time, can correct the sync problem, I think it will be better. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108160225.LAA08355>