Re: oskit driver for i8042 keyboard controller

[Marcus Brinkmann]

On Fri, Nov 08, 2002 at 06:26:09PM -0500, Roland McGrath wrote:
> > it won't be a problem in my console, as I am opening it once with read/write
> > permission.  But of course it needs to be fixed.  I don't know where the
> > three references come from.  They are not increased by subsequent
> > open/close, so they might come from the code that creates and enters the
> > device, not sure.  I would need to do more debugging if it isn't something
> > obvious to you.
> 
> Hmm, that's not obvious to me off hand.  I would have to go debug it myself
> to get a handle on it.  

Ok, I can try to find out where the references come from.

We have some good and some bad news.  The good news is that I now have a
hacked pc kbd driver for scancode set 2, and also implemented the kbd led
thingie.  Because the console already supported this, everything works now,
not only local state like caps lock and num lock, but also external state like
scroll lock (which is per VC).  So that was quite easy.  I now have to clean
up the code to not rely on the big #ifdef, and maybe I will also add a
feature to set kbd rate/delay while I am at it.  That would make it quite
usable already.

The bad news is that there are bugs ;)

Right now what I am doing is to read from kbd byte by byte.  I will change
it to read many bytes at once (as much as the internal buffer is), and then
process the local buffer first, before reading more.  However, reading byte
by byte should also work I would think.  The bug I am seeing is that one
byte gets stuck:

I just released a key (let's say "p"), but I only read F0.  When I press the
next key ("q") down, the scancode for "p" is read.  The next read does probably
not return anything (hard to say because of key repeat) until I release the
key, then I can read two bytes, the scancode for the key I pressed ("q") and
the "F0" of releasing the "q".  The "q" for the release is only read with
the next key press etc.  It works before I press CAPS but not afterwards. 
Roland, is there a problem with writing to the device while the user presses
keys?  maybe there is some race there.

Another serious bug is that my I/O permission stuff is not working properly.
There seems to be a race of some sort.  Sometimes I just get SIGILL when
writing to VGA ports.  The VGA ports are higher than the speaker ports. 
When and where this happens is entirely random.  I guess I have to set up a
break point in the kernels SIGILL handler or so, and check out the processor
state.  Of course it could be something very subtle like the need to flush
or update something after installing the IO ports at a task switch.  Or
maybe it's just that I am not pausing (I am using out, not out_p, but I
think that should work, and not cause a SIGKILL anyway).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/