OSDev.org

Currently my keyboard handler processes the scancode and possibly calls a function to figure out what should be done with the input, which possibly calls another function to print something, and so on.

I have a strong feeling this is not the right way to do things, because the keyboard handler code shouldn't run the entire OS.

So how exactly to process the keys properly? Store them in a queue?
More specifically, what should the keyboard handler be doing?

Espanish wrote:Currently my keyboard handler processes the scancode and possibly calls a function to figure out what should be done with the input, which possibly calls another function to print something, and so on.

I have a strong feeling this is not the right way to do things, because the keyboard handler code shouldn't run the entire OS.

So how exactly to process the keys properly? Store them in a queue?
More specifically, what should the keyboard handler be doing?

Process(es) read(s) from stdin, the keyboard handler sends the bytes to the process, on which the user is focused.

My keyboard interrupt handler just makes the keyboard thread runnable. They keyboard thread then reads from the controller, decodes the scancode and stores the result in the keyboard buffer (unless it's full), which is a simple circular queue. Doing this on a thread rather than the interrupt handler simplifies the mutex arrangements for the buffer.

Programs can read from the keyboard device (exposed to userspace via the filesystem API, ala UNIX), which dequeues the decoded values from the buffer. The terminal driver provides an additional layer of abstraction, providing "standard input/output" concepts, multiple virtual terminals, etc. Userspace programs generally communicate only with the terminal device and not the keyboard device directly.

In my case, it forwards the scancode to the window manager, which first does it's own thing (like detect if the Windows key was pressed), and if there's a focused window, it sends that process a KEY_STATE message.

My keyboard handler simply stores the key presses on a buffer shared between all keyboards (unless the buffer is full). A shared buffer means my kernel doesn't need to worry about searching each keyboard driver there may be in the future for key press/release events. My shell continuously loops waiting for a keypress to appear on the buffer (unless it is busy running a command).

You can either place the translated scancode in a circular queue, and wait for an interested application to retrieve it, or you can, like Windows, send the foreground process a message saying, some input from the keyboard has arrived, and here it is.

Thanks for the suggestions, everybody.

The circular queue idea seems too complex for my needs. If I understand the idea correctly, the handler pushes new scancodes to the queue while the kernel is busy-waiting for the queue to fill up, to pop the scancodes.

(What if the kernel is in the middle of popping and then the user hits a key? Disable interrupts beforehand?)

The message idea seems simpler, but I don't know how a "message" is supposed to be implemented.
I suppose using a global boolean kb_touched that is polled defeats the purpose.

How are messages normally implemented for such purposes?

Espanish wrote:Thanks for the suggestions, everybody.

The circular queue idea seems too complex for my needs. If I understand the idea correctly, the handler pushes new scancodes to the queue while the kernel is busy-waiting for the queue to fill up, to pop the scancodes.

Think about the BIOS's keyboard handler. When int 9 goes off it retrieves the scan code, translates it into an ascii character, and then stores it in a buffer until somebody wants it. A program wanting keyboard input then issues a int 16h, and retrieves the character at the head of the queue; assuming that the queue is not empty.

Which approach works best will depend upon the design of your operating system.

Espanish wrote:(What if the kernel is in the middle of popping and then the user hits a key? Disable interrupts beforehand?)

Things start getting complicated when you share mutexes between threads and interrupt handlers, I'm still figuring it out myself too: http://forum.osdev.org/viewtopic.php?f= ... 72#p243472