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 [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
