Is it possible to write a simple C source to allow the user to type something, from my kernel, and then just save the letter they typed into a char or an int or something?
Thanks in advanced
Ched
C keyboard handler?
-
anton
RE:C keyboard handler?
You can save the chars into a array of bytes if no special chars are used(Alt, Ctrl, F1,...), else you
will need to use a array of words(2 bytes).
Anton
will need to use a array of words(2 bytes).
Anton
-
carbonBased
RE:C keyboard handler?
You have to install a keyboard handler ISR (IRQ 1). Within that handler you must read the current keystroke (if memory serves, it's available from port 0x60). You must also acknowledge to the keyboard that you have, indeed, read that keystroke (so that it continues to send new keystrokes)... I don't recall how to do this offhand (check http://www.nondot.org/sabre/os/articles ... ceDevices/, 'cuz I don't remember offhand how to do this).
That's it, you're done. It's incredible simple, just check up on keyboard docs. GazOS also had a simple keyboard driver that included LED and scan code conversions that might be useful to you.
Jeff
That's it, you're done. It's incredible simple, just check up on keyboard docs. GazOS also had a simple keyboard driver that included LED and scan code conversions that might be useful to you.
Jeff
-
Schol-R-LEA
RE:C keyboard handler?
Piece of advice: have ISR the store the scan codes (*not* the translated results) in a ring buffer (say, a 256-byte array whose pointer is incremented as
current++;
current %= 256;
or something along those lines - keeping in mind that some scan codes are more than one byte in size, and would have to be handled accordingly), and set whatever kind of flag or message is appropriate under your kernel so that, after you return from the ISR, it will invoke a secondary keyboard handler which does all the translation, etc. This means, among other things, you can't get stuck in the ISR with the interrupts locked while dealing with some particularly elaborate scan code result (i.e., CRTL-ALT-ESC-Q or some such). Now, it does mean that there is no true 'raw' (unbuffered) mode, but with a suitable keyboard handler it shouldn't make a difference.
current++;
current %= 256;
or something along those lines - keeping in mind that some scan codes are more than one byte in size, and would have to be handled accordingly), and set whatever kind of flag or message is appropriate under your kernel so that, after you return from the ISR, it will invoke a secondary keyboard handler which does all the translation, etc. This means, among other things, you can't get stuck in the ISR with the interrupts locked while dealing with some particularly elaborate scan code result (i.e., CRTL-ALT-ESC-Q or some such). Now, it does mean that there is no true 'raw' (unbuffered) mode, but with a suitable keyboard handler it shouldn't make a difference.
-
Hillbillie
RE:C keyboard handler?
>I don't recall how to do this offhand<
Reading a byte from port 0x60 is what tells the keyboard you're ready for more scancodes (if they're available).
I've recently completed a nice keyboard driver in C. If anyone wants some p2p help (not code, so don't even ask) e-mail me at j_freeman[AT]conwaycorp.net.
Reading a byte from port 0x60 is what tells the keyboard you're ready for more scancodes (if they're available).
I've recently completed a nice keyboard driver in C. If anyone wants some p2p help (not code, so don't even ask) e-mail me at j_freeman[AT]conwaycorp.net.