Subject: Re: cost of gettimeofday()
To: None <current-users@netbsd.org>
From: Peter Seebach <seebs@plethora.net>
List: current-users
Date: 03/08/2002 11:58:03
In message <Pine.WNT.4.43.0203081250400.1200-100000@todd>, Todd Vierling writes
>: This pause is, I suspect, detectably longer than the delay between adjacent
>: bytes of real mouse input.

>Is there any way to, say, read 3 bytes, and from that, determine if the
>event should have a 4th byte pending (and use the different protocol)?

Unfortunately, no; the fourth byte is purely independant of the first
three.  Essentially, it's the same 3 bytes, plus an additional byte which
holds the z movement, and possibly buttons 4 and 5.  This is a particularly
stupid thing for the KVM switch to get wrong.

>: So, if I changed psm.c to call gettimeofday() every time it got a byte of
>: data, check for long delays... Is this a bad idea?

>Well, not gettimeofday() per se, but getting the system tick clock as a
>rolling timestamp each time an event fires should be fine, IMHO....

Fair enough.  What's the canonical way to do this?

-s