From owner-freebsd-hackers Mon Apr 8 06:43:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA26740 for hackers-outgoing; Mon, 8 Apr 1996 06:43:53 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA26731 for ; Mon, 8 Apr 1996 06:43:49 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA07711; Mon, 8 Apr 1996 08:41:27 -0500 From: Joe Greco Message-Id: <199604081341.IAA07711@brasil.moneng.mei.com> Subject: Re: The F_SETOWN problem.. To: roell@blah.a.isar.de (Thomas Roell) Date: Mon, 8 Apr 1996 08:41:27 -0500 (CDT) 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 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > 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 > 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 > driver in FreeBSD (and much worse in Interactive UNIX) has only a > limited buffer. Assume you have 1024 bytes, then you can buffer only > 341 packets (and one additional byte). If the mouse reports 50 times > per second the position, then after roughly 7 seconds you loose sync > if you are unable to read the input (3 seconds with ISC). If you run > now X-clients which are hogging the X-server with requests that are > longrunning (like mpeg_play) and you move the mouse for a while you > might want to restart the X-server to get the mouse into sync again. The other "solution" (the only solution, IMHO) to this "problem" is to sit back and consider why "restarting" the X-server gets the mouse into sync again. It doesn't. You're gambling that at some point, the user stopped moving the &*$&*^@#^$ mouse in order to go restart the Xserver, which implicitly resyncs you. Now you have to go build your mouse driver to be time-aware in addition to bytestream-aware. And you can find an arbitrary rule that works, maybe something like "if the mouse hasn't given me input in 10 seconds, set input automaton to state 0". You can even publicize it to your users. That is, perhaps, not the prettiest solution, but sometimes you take what you can get with cheap hardware. I've been there, done that, even with some fairly pricey hardware. I know it sucks to have to write a "clever" driver :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968