From owner-freebsd-current Wed Nov 13 10:56:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06234 for current-outgoing; Wed, 13 Nov 1996 10:56:14 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06181; Wed, 13 Nov 1996 10:55:59 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA00978; Wed, 13 Nov 1996 11:55:50 -0700 (MST) Date: Wed, 13 Nov 1996 11:55:50 -0700 (MST) Message-Id: <199611131855.LAA00978@rocky.mt.sri.com> From: Nate Williams To: sos@freebsd.org Cc: bde@zeta.org.au (Bruce Evans), nate@mt.sri.com, freebsd-current@freebsd.org, jkh@time.cdrom.com, wangel@wgrobez1.remote.louisville.edu Subject: Re: your mail In-Reply-To: <199611131852.TAA21608@ravenock.cybercity.dk> References: <199611131804.FAA11738@godzilla.zeta.org.au> <199611131852.TAA21608@ravenock.cybercity.dk> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >> The fix also broke PS/2 mouse support. :( :( > > > > > >I know :(, but so long as we occasionally looses an interrupt, there > > >is not much else to do. Or merge syscons and the ps/2 mousedriver. > > > > Lots can be done: > > - back out fix OR > > Bad idea keyboards will hang all over the globe... Is the bug that the 'set ipending=2' bug that many of us are seeing? > > - poll less often (fixed period) OR > > - poll less often (after keyboard has been inactice for a while) OR > > Will still break the psm device, just more seldom... Or less often even. ;) > > - make fix a compile time option OR > > - make fix a run time option OR > > Hmm, run time optime could be an idea... > > > - check for psm interrupt and don't poll keyboard if one is pending OR > > which bits to poll for that ??, and its difficult to know if a keyboard > int has been lost already, so who's data is it we're reading... The suggestion I made to the psm author is to have *one* read routine, which somehow can distinguish between keyboard and mouse reads. (Easier said than done). If a read is for the other device, it is queued up for that device to read earlier or their interrupt routine is called. It's not a *really* hard problem, but it's not necessarily an easy problem to work either. Nate