Date: Wed, 13 Nov 1996 11:55:50 -0700 (MST) From: Nate Williams <nate@mt.sri.com> 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 Message-ID: <199611131855.LAA00978@rocky.mt.sri.com> In-Reply-To: <199611131852.TAA21608@ravenock.cybercity.dk> References: <199611131804.FAA11738@godzilla.zeta.org.au> <199611131852.TAA21608@ravenock.cybercity.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611131855.LAA00978>