From owner-freebsd-current Wed Nov 13 11:41:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09311 for current-outgoing; Wed, 13 Nov 1996 11:41:27 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA09306 for ; Wed, 13 Nov 1996 11:41:22 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id GAA13980; Thu, 14 Nov 1996 06:35:35 +1100 Date: Thu, 14 Nov 1996 06:35:35 +1100 From: Bruce Evans Message-Id: <199611131935.GAA13980@godzilla.zeta.org.au> To: bde@zeta.org.au, sos@ravenock.cybercity.dk Subject: Re: your mail Cc: freebsd-current@freebsd.org, jkh@time.cdrom.com, nate@mt.sri.com, wangel@wgrobez1.remote.louisville.edu Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> - 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 psm bit in ipending. We already check the KB_BUF_FULL bit, so there should be no races: an IRQ should have occured since there is some data, but we haven't processed it because of the spltty(). I hope that IRQs are serialized so that ones for the keyboard and the psm don't happen concurrently. Then ipending gives lots of information: ipending & kbd_IRQ && !(ipending & psm_IRQ) => scancode for keyboard !(ipending & kbd_IRQ) && ipending & psm_IRQ => scancode for psm ipending & kbd_IRQ && ipending & psm_IRQ => can't happen, we hope !(ipending & kbd_IRQ) && !(ipending & psm_IRQ) => oops, lost kbd IRQ Bruce