Keyboard Driver

[K.J.]

Okay, I have my PIC remapped and IRQ 1 enabled. Whenever you touch a key on the kerboard, my OS just says, "you hit the keyboard". I've looked at Chris Giese's code, but it outputs everything typed to the screen.

What I want to do is be able to display what is typed on the screen, but I also want to be able for my OS to do something depending on what is typed(like run a program). So, should I have the driver output to the screen and to say, a 100 charactor array that my OS could check every now and then? I think that that would take to much CPU time to check the array. I want to not have to change the driver much when I get a GUI on my OS. Any suggestions?

Thanks in advance,
K.J.

[Tim]

You are about to enter the potentially huge area of your kernel's driver interface .

Generally, a keyboard driver's interrupt handler will put keys into a buffer. When a keyboard read request is received, some other part of the driver will check that buffer; if it is not empty, it will return the first character(s) to the calling application and update the buffer. Read up on the way the PC BIOS does things for a simple example.

This same scheme can be followed for most other input devices (e.g. mice): read data from the device in the ISR and put it in a buffer; read data from the buffer when it is asked for.

The other way is for applications to request data and have the driver ask the device for it. For example, a hard disk driver will receive read requests and ask the drive for a given sector. When this sector is ready (when an IRQ is received) the driver will put the data into the application's buffer and notify it that the data are ready. Simple kernels such as Linux will put the application to sleep until the request has finished; more capable ones such as NT will optionally keep the thread running and notify it when the request has finished.

Read my "Device Management" tutorial for some more explanation...

[K.J.]

So, when IRQ 1 happened, the ISR would call a function in the kb driver that would store the charactor in a (small? large?) array. Then in the OS idle loop, the OS would call the kb driver and see if any charactors are availible? Would this work with multitasking?

Hmm, didn't notice the device managment tutorial before, I'll have to read it and add it to my site!

Thanks,
K.J.

[df]

well i was more of the thought that each active app has its own keyboard buffer, and the keyboard driver stores keys in the active app (be it kernel or userland program), this stops things getting mixed up.

[Tim]

Then in the OS idle loop, the OS would call the kb driver and see if any charactors are availible?

No, the keyboard driver checks the buffer when an application asks to read from the keyboard.

Here's the sequence of events:
1. The shell loads and asks for one character from the keyboard.
2. The keyboard driver gets the read request but the buffer is empty, so it queues the request and puts the shell to sleep/tells it to wait.
3. The shell waits.
4. A keyboard interrupt comes along; the keyboard ISR puts the scan code in the buffer.
5. The keyboard driver walks the list of queued requests and gives a key to any application that wanted one.
6. The shell is given a key and is woken up.

You can extend this to several buffers if you want (one for each terminal/application).

[K.J.]

Okay, now I just have to code it.

K.J.

[K.J.]

2 questions:

1) Should I have the driver convert the scan code to a charator or not?

2) Assuming that the above is done, how do I give an app a Fx key and have the app know what it is?

If anyone wants to see my KB driver and give some tips and/or use soom code from it, it's availible here:
http://users.demented.org/~osmaker/down ... kernel.zip

Thanks in advance,
K.J.

[df]

i turned each key press into a 32bit long. each long stored keyboard state (ie: when that key was pressed, it stores the alt's, ctrl's, 'win' keys, etc, so you get a full state with each keypress in a single entry).

[K.J.]

Could you please be a little bit more specific DF?

K.J.