From owner-freebsd-current Thu Feb 13 12:52:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07380 for current-outgoing; Thu, 13 Feb 1997 12:52:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07375 for ; Thu, 13 Feb 1997 12:52:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA00873; Thu, 13 Feb 1997 13:51:29 -0700 From: Terry Lambert Message-Id: <199702132051.NAA00873@phaeton.artisoft.com> Subject: Re: moused on notebooks... To: gurney_j@resnet.uoregon.edu Date: Thu, 13 Feb 1997 13:51:29 -0700 (MST) Cc: terry@lambert.org, freebsd-current@freebsd.org In-Reply-To: from "John-Mark Gurney" at Feb 12, 97 07:40:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > would anybody object to possibly added a signal handler to moused for > > > SIGHUP to force it to reopen the mouse device? comments? > > > > In the situation you describe, the SIGHUP would arive when you > > unplugged the mouse, not when you plugged it in. You want it to > > be opened *after* you plug it in. > > that's if your using a normal serial mouse... but I'm using a ps/2 > mouse... so there isn't a "disconnect" signal... as far as I know... of > course I guess I should make the SIGHUP patch affect bus and ps/2 mice > only then... > > currently as it stands moused dies when it recieves a SIGHUP.. :) So you want to be able to manually SIGHUP it? That doesn't really solve the problem; all it does is provide a kludgy workaround. The problem is: 1) Knowing you need to reinit the PS/2 mouse channel of the keyboard controller, at all. 2) Knowing when you need to resync the command stream because someone has done something dumb like plugging and unplugging the thing. For suspend modes, that's the job of the particular device driver. Many devices (like the video drivers) don't know how to restore modes... for instance, how do I, as the console driver, put the console backinto a mode usable by X, after it the machine comes back up from suspend? I can't, if X is allowed to write to the video controller I/O ports, many of which are write-only. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.