From owner-freebsd-hackers Sun Apr 7 06:27:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA12049 for hackers-outgoing; Sun, 7 Apr 1996 06:27:11 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA12044 for ; Sun, 7 Apr 1996 06:27:09 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id XAA06599; Sun, 7 Apr 1996 23:23:08 +0930 From: Michael Smith Message-Id: <199604071353.XAA06599@genesis.atrad.adelaide.edu.au> Subject: Re: The F_SETOWN problem.. To: roell@blah.a.isar.de (Thomas Roell) Date: Sun, 7 Apr 1996 23:23:08 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com In-Reply-To: <199604071245.OAA00414@blah.a.isar.de> from "Thomas Roell" at Apr 7, 96 02:45:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thomas Roell stands accused of saying: > > Er, almost certainly not. Try "low-cost asynchronous input". Remember > > what TR does? Think about how handy it would be to do your mouse data > > handling inside a signal handler; your main loop would be presented > > with events out of a FIFO as faits accompli, you could probably even > > stuff the location registers in the signal handler. > > 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) > X-Server). Of course you can move the mouse pointer directly in the > signal handler (although this is EXTREMELY tricky). I can imagine 8) > 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. > 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) > - Thomas -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[