> > 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

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.


>  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
>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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to