From owner-freebsd-hackers Sun Jun 21 22:22:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA16494 for freebsd-hackers-outgoing; Sun, 21 Jun 1998 22:22:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles314.castles.com [208.214.167.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA16460; Sun, 21 Jun 1998 22:22:38 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id SAA02633; Sun, 21 Jun 1998 18:29:23 -0700 (PDT) Message-Id: <199806220129.SAA02633@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Danny Dulai cc: Mike Smith , Randall Hopper , hasty@rah.star-gate.com, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: X-10 Mouse Remote patch In-reply-to: Your message of "Sun, 21 Jun 1998 20:29:21 EDT." <19980621202921.57824@bleep.ishiboo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jun 1998 18:29:23 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Right now, there is no way I can get the remote output that moused gives > to /var/run/MouseRemote, and still run other mice on moused, AND > having the remote's mouse functions disabled. > > The mouse remote's rf receiver gets far too much interference and causes > my mouse pointer to jump around and buttons to be pressed randomly. The > remote is uesless without turning off the mouse support. > > To solve this problem either add an option to moused to turn off mouse > messages (and rename moused to something better), or use the model I > suggested using remoted that splits mouse and remote events. > > Randall has expierenced the problems I'm getting, and I assume most > others that have this remote do too. This is not a feature that '[isnt] > worth the effort', its a mandatory feature for functionality. Drivers should, as a general rule, cater to hardware that is working correctly. If you have a decent general-purpose heuristic that helps with a given failure mode, that's one thing, but attempting to kluge around hardware that is failing in a completely random fashion is pointless. If you want the split, we can talk about the modular architecture I originally proposed, presuming of course that you're interested in discussing or implementing it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message