Re: oskit driver for i8042 keyboard controller

[Marcus Brinkmann]

On Mon, Oct 21, 2002 at 03:38:43AM -0700, Roland McGrath wrote:
> This driver handles only the lowest level of the PC keyboard & PS/2 mouse
> interface, and does almost the minimal work it can do.  It is an oskit
> "bus" device like ide or scsi busses are, and has (at most) two slots,
> called "kbd" and "aux".  Each of these devices can be opened to get an
> object supporting the stream and asyncio interfaces, which is what
> oskit-mach knows how to use for serial-like devices.  You should be able to
> use the bus-walk syntax "@>=kbd" and "@>=aux" in device_open in oskit-mach.
> For testing with cat or whatever, /hurd/streamio should work fine with these.

Confirmed.  What is the non-bus-walk name of these devices (just curious)?

> This gets you raw byte i/o to the kbd or mouse/aux device, so there is
> still some of the low-level protocol to be implemented at user-level.  The
> only part of the protocol with the devices (as opposed to the controller)
> that the driver handles is the ACK/NAK of bytes you send to the device.
> You write command bytes to the device to set the LEDs and for who knows
> what with the mouse protocols, and in the hardware these have to be sent
> one byte at a time waiting for an ACK byte from the device.  This part I
> handle in the kernel, so device_write(_inband) RPC fills a tiny internal
> buffer from which the driver sends a byte at a time from the interrupt
> handler as the ACK bytes arrive.  Otherwise the writing of command bytes
> from user level would get really out of hand.

Ah, which reminds me that I still use device_read and not
device_read_inband, in my kbd driver.

Writing of the bytes doesn't seem to work properly, I set up streamio
(cat'ing from that works fine), and then I tried

echo $'\xED\x07' > kbd

which should activate all the LEDs, but instead nothing happened and it just
blocked interruptibly.  I have to leave now, but can debug it later.  Or you
can write another test kernel and debug it without running the Hurd at all,
I guess.

> I think this is the appropriate lowest reasonable level of functionality to
> have in the kernel.  The driver disables the i8042's scancode translation
> feature, so that what you are getting are the raw bytes from the keyboard.
> There are so many levels of translation involved in the Linux and BSD
> drivers that I have no idea whether or not the raw scancodes are the values
> you're used to seeing at user level.  Anyway, I decided you should get it
> as direct as it can be got.  

It doesn't seem to be the mapping I am using currently.  For example, escape
is 0x76, but in GNU Mach 1 it is 0x01, F1 is 0x05, formerly 0x3b.  I am not
sure where the difference comes from, I will try to find it out.
 
> For the Hurd console input code, drivers are now needed for talking to the
> keyboard and mouse by using device_read/write_inband on these raw devices.
> For the keyboard there isn't much to it, but the mouse I don't know about.
> In other systems this level of the protocol is in the kernel as well, so
> reading more of the Linux and NetBSD drivers is how I would find this stuff
> out if I were going to write those modules.  

I am sure we will work it out.

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/