Date: Fri, 14 Feb 1997 09:17:22 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: gurney_j@resnet.uoregon.edu, terry@lambert.org Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: moused on notebooks... Message-ID: <199702140017.JAA07730@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Thu, 13 Feb 1997 13:51:29 MST." <199702132051.NAA00873@phaeton.artisoft.com> References: <199702132051.NAA00873@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> > > 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. This can be done, by hooking the resume event hook provided by the apm0 driver. I will write a piece of code for the psm driver to do just that if such modification is useful/necessary for the suggested moused enhancement. >2) Knowing when you need to resync the command stream because > someone has done something dumb like plugging and unplugging > the thing. Well, if the moused is to reopen the device, it can resync with mouse data stream at that moment, I think. Kazu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702140017.JAA07730>