Date: Thu, 16 Aug 2001 12:06:54 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Joe Kelsey <joe@zircon.seattle.wa.us> 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: <200108160306.MAA08522@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Wed, 15 Aug 2001 14:20:58 MST." <15226.59322.424480.324816@zircon.zircon.seattle.wa.us> References: <200108150924.SAA06230@zodiac.mech.utsunomiya-u.ac.jp> <15226.59322.424480.324816@zircon.zircon.seattle.wa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Too complicated? > >It sounds fine to me. I was thinking that if you are truly concerned >about the amount of time that the disable/enable calls take, the way to >solve that is a combination of counter and timer. Increment a counter >when you take the disable/enable path to prevent recursive calls. Set a >timer the first time through the pair of functions to get the basic >timing down. Then, limit the calls to the pair of functions so that you >never call them closer than 10x the time to complete the pair. (maybe >100x the time is better? It depends on how long the function pair >actually takes to complete. Is it variable depending on MB or other >factors?) I think that timing the calls is important to limit the >possibility of calling the functions too often in case of pathological >circumstances. This seems to be the overriding concern anyway. I have >only seen the problem once since I enabled that flag. We don't need to worry about such situation. As soon as we send the disable command to the mouse, it will stop sending data packet. So, we are not going to send another disable command before it completes, because we won't get another data byte which looks "out-of-sync" before the enable command. If we get "out-of-sync" data bytes after we send the enable command, there are two possible reasons: a) Disable/enable didn't work. The data packet is in wrong format. We need reset/re-initialization. b) The disable command was sent while the mouse was sending a data packet, and the mouse tried to send the remaining part of the packet after the enable command. This shouldn't happen for the well-behaved mouse. Logitech's technical document states that if the mouse is disabled in the middle of a data packet, the unsent part of the packet will be discarded, and the mouse will start sending a new packet after the next enable command. But, I would be rather cautious about this; there are so many wacky mice out there; they may not be as good as Logitech's :-) So, I would rather wait few more times after disable/enable and before reset/re-initialization. >What happens if you set your KVM into cyclical mode? Does it force a >mouse interrupt when it switches from machine to machine? It depends on the KVM's firmware, doesn't it? Both the mouse and the host computer do not know they are connected to a KVM. If the mouse is somehow forced by the KVM to send a data packet whenever you switch between machines, we will see the mouse interrupt. Otherwise I cannot imagine the mouse voluntarily sending data packets when you switch machines. You see, the root of the problem is here. The KVM tries to be transparent to the host computers and the mouse (and the keyboard) and there is no way for the host computer and mouse to know that it is connected to a KVM and to know exactly when the user switch between the machines. Kazu > I can imagine >a KVM misbehaving during the automatic rotate mode to cause a real >cascade of problems. On the other hand, if you put it in the rotate >mode, you probably aren't touching the mouse, so it shouldn't cause >problems. > >How difficult is it to keep some sort of timer value in the code? If it >costs too much to get a timer, then a counter is probably sufficient. > >/Joe 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?200108160306.MAA08522>