Date: Wed, 13 Nov 1996 22:03:09 +0100 (MET) From: sos@freebsd.org To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, freebsd-current@freebsd.org, jkh@time.cdrom.com, nate@mt.sri.com, wangel@wgrobez1.remote.louisville.edu Subject: Re: your mail Message-ID: <199611132103.WAA09059@ravenock.cybercity.dk> In-Reply-To: <199611131935.GAA13980@godzilla.zeta.org.au> from "Bruce Evans" at Nov 14, 96 06:35:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Bruce Evans who wrote:
>
>
> >> - 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
Or lost psm IRQ :(
OK, I'll put code in for this and check the results, that might bring
some elight over what happens...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611132103.WAA09059>