Date: Sun, 7 Apr 1996 20:39:34 +0200 From: Thomas Roell <roell@blah.a.isar.de> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: roell@blah.a.isar.de (Thomas Roell), terry@lambert.org, hackers@freebsd.org, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604071839.UAA00701@blah.a.isar.de> In-Reply-To: <199604071353.XAA06599@genesis.atrad.adelaide.edu.au> References: <199604071245.OAA00414@blah.a.isar.de> <199604071353.XAA06599@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In your message of 7 April 1996 you write: > > Was it that obvious ;-) Actually two reasons why I need it. One is > > In context, there really weren't too many other things you could want > it for, unless perhaps you wanted to put dongle support in AccelX 8) Dongle ... good idea. I have to ask our marketing about that ! > > The other reasons is more tricky. We do have reports from people that > > under heavy load they loose sync of the PS/2 mouse. The PS/2 mouse is > > I must say I'm not entirely sure that signal delivery will help lots > here; certainly it would get your reads happening as soon as the > server ran again. Well I guess there is a long explanation necessary. First off it should be obvious why SIGIO solves any possible problem, since the signal-handler can process the input directly, and even if it just means to buffer it in a larger buffer. Now a X-Server does some really tricky things to lower the cost of a dispatch cycle. Basically input-devices are ONLY polled after a select() system call. However one gets only back to the select system call if there is no more data left from the previous select() call, which means a client that overruns the X-Server with data can basically lock out any io. And if this happens long enough, the kernel-device buffer will overflow. > > different from all other mice, as there is now way to figure out from > > the byte-stream when a 3 byte packet starts. There is supposed to be a > > sync-bit, but half of the PS/2 mice do not set it. The PS/2 kernel > > Ah, I've been here before 8) If you can at all, use an idle timeout. > If you have no mouse traffic for a second (or two or three), reset > your state machine. I'm aware that this won't help the heavy traffic > sync loss that you'll get if the buffer's overrun, but it will get > you back in sync if you leave the mouse alone. > (apologies if I'm trying to teach you to suck eggs 8) We are doing exactly this already. But still the effect is quite noticable for certain applications. The customer really didn't like my comment about his broken hardware ;-) - Thomas -- Denver Office THOMAS ROELL /\ Das Reh springt hoch, +1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit, 1801 Broadway, Suite 1710 / \ \/\ was soll es tun, Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604071839.UAA00701>