OSDev.org

ok, can anyone give me an example of all of the things i need for keyboard input?

jockepockee wrote:ok, can anyone give me an example of all of the things i need for keyboard input?

A keyboard and a computer....

Try to be a little more... specific with your posts..

http://www.osdev.org/wiki/Keyboard_Input Should clear a few things up.. (The article could be extended further..)

jockepockee wrote:ok, can anyone give me an example of all of the things i need for keyboard input?

A keyboard, something to connect it to and some input.

If you want a more specific answer, make a more specific question.

you write a valid IDT and GDT table, remap the pic and then re enable interrupts.

not even necessary: just poll it

When you strike a key the keyboard contoller outputs a signal on the IRQ1 line in order to get the CPU's attention. Commonly this means that a type 9 interrupt is generated. However, since this conflicts with one of Intel's reserved interrupts the PIC either has to be reprogrammed so that something other than a type 9 interrupt results from a signal on the IRQ1 line, or else the interrupt 9 handler must be able to distinguish between an interrupt arising from keyboard activity and one arising from within the CPU itself.

Either way, the interrupt service routine invoked by a signal on the IRQ1 line is responsible for retrieving a scan code from the keyboard controller via port 60h, and then turning it into a meaningful ascii or (if you're really ambitious) unicode character. What it does with it then is for the programmer to decide. Usually it is stored in a circular queue so that the OS can collect it at some later time, and pass it on to an application program.

Clearly, all of that presupposes that you have intialised an IDT.

mathematician wrote:Commonly this means that a type 9 interrupt is generated.

The terminology reminds me of medicine. We have a type O negative interrupt!



On topic though, what if the poster was interested in the keyboard connected to a SparcStation 5? I have one here so if anybody has a serious comment, I'll test it for you on a real device. It's also apparently simulated in QEMU. You can use the HD if you like but I prefer it to be left alone as its 15 years old or so.

I'd like to know how to get input from the keyboard attached to my terminal attached to my PA-RISC machine. But, as i can't even get a working cross-compiler for it, I doubt that would be a useful question. Unless you count knowledge for knowledge's sake as an argument

Seriously, I think its safe to assume a desktop pc "unless stated otherwise"

Hi,

jockepockee wrote:ok, can anyone give me an example of all of the things i need for keyboard input?

A general list of thing you might need:

• Code to get the OS booted, switch the CPU into the intended operating mode, memory management, scheduling, IPC, and file I/O (some of this may be optional, depending on OS design).
  
  Code to setup IRQs. This might be code to remap PICs, code to detect if an interrupt came from the PICs or from an exception, and/or code to setup I/O APICs. It may also involve setting up an IDT or IVT if you haven't already.
  
  Code to detect if a "PS/2 port controller" (or keyboard controller) chip is actually present, and run diagnostic tests, determine if the chip supports one PS/2 port or 2 of them, and configure it. You might consider this is optional (lots of hobby OS developers simply assume the "PS/2 port controller" is present, working and configured suitably by the BIOS).
  
  Code to detect which PS/2 devices are connected to which PS/2 ports. This may also involve code to check if PS/2 devices are removed or plugged in while the OS is running (e.g. re-check the devices every 2 seconds). You might consider this optional too.
  
  Code to initialise the keyboard itself, including running diagnostics, and setting LEDs, key repeat delays, etc.You might consider this optional too.
  
  Code to install an IRQ handler and the IRQ handler itself.
  
  Code to convert raw scancodes into whatever the OS uses (which could be a ASCII stored in a simple FIFO buffer, messages sent via. IPC containing unicode characters and extended information or something else). Optionally, this might involve loading translation tables from disk, so that different keyboards can use the same driver with different translation tables. Alternatively you could write a different keyboard driver for each different keyboard (with "hard-coded" translation), or avoid internationalisation completely.
  
  Some sort of software interface to allow different "input method editors" to be used. This is optional too (mainly for internationalisation).

I'd recommend starting from the top of this list and working towards the bottom, skipping things you don't want and only worrying about what's involved for a next item in the list. When you reach the bottom of the list and everything is working well, start working on PCI device detection, then USB controller support, then USB keyboards...


Cheers,

Brendan

I send the input's scan code to the current process, then let that handle it. In my default window library, it sends the key input to the currently focused control. If the control is a textbox, it adds the character into the textbox's buffer .

MessiahAndrw wrote:I send the input's scan code to the current process, then let that handle it. In my default window library, it sends the key input to the currently focused control. If the control is a textbox, it adds the character into the textbox's buffer .

I would say that's cheating. What sort of OS is it which sends scan codes to applications instead of usable ascii codes? One of the things the operating system is there for is to save applications that kind of hassle.

It sounds like your OS is going to be even more user unfriendly than Linux, which is saying something.

mathematician wrote:

MessiahAndrw wrote:I send the input's scan code to the current process, then let that handle it. In my default window library, it sends the key input to the currently focused control. If the control is a textbox, it adds the character into the textbox's buffer .

I would say that's cheating. What sort of OS is it which sends scan codes to applications instead of usable ascii codes? One of the things the operating system is there for is to save applications that kind of hassle.

It sounds like your OS is going to be even more user unfriendly than Linux, which is saying something.

Actually, decent OS sends both the scancodes and the ascii codes, because they are useful for different things.

Typically you'd use about three types of messages: KeyPressed, KeyReleased, and KeyTyped. When the application is interested in the pressed/released events, it's probably easier to deal with scancodes than ascii codes. With typed-events on the other hand, you care about text, so text should be sent.

Such separation between keyboard presses/releases and text-input also makes sense if you ever want to support input methods for languages that need more than just a key-to-character mapping. In fact, even most latin scripts have various characters with accents and umlauts and what not (á,è,ï,õ and so on) that need more than just a simple mapping.

Whether using the hardware scancodes is a good idea, is another thing. It might make sense to remap them to a new set of internal codes which gets rid of stuff like multi-byte special cases.

mathematician wrote:

MessiahAndrw wrote:I send the input's scan code to the current process, then let that handle it. In my default window library, it sends the key input to the currently focused control. If the control is a textbox, it adds the character into the textbox's buffer .

I would say that's cheating. What sort of OS is it which sends scan codes to applications instead of usable ascii codes? One of the things the operating system is there for is to save applications that kind of hassle.

It sounds like your OS is going to be even more user unfriendly than Linux, which is saying something.

The library handles converting the scan codes into ASCII. Because what if you had a keyboard with extended keys and a special program to use them? Should the OS send a bunch of \0's to the program so it can't detect which key is which?

EDIT: I'm also going to make a full screen game library later, which will need to know the keyboard scan codes. Most of my OS is designed to be expandable. The mouse driver doesn't store the X and Y position of the cursor, that's the GUI's job. The mouse driver just returns how much to offset it by, so in my game library you can read this offset directly, and not worry about if the mouse cursor has hit the edge of the screen and the player can't turn anymore. And the game library has direct access to the screen buffer in full-screen, that way screen drawing calls don't have to pass through my GUI messaging system (program->GUI->driver->buffer like other programs do).

Hi,

MessiahAndrw wrote:The library handles converting the scan codes into ASCII. Because what if you had a keyboard with extended keys and a special program to use them? Should the OS send a bunch of \0's to the program so it can't detect which key is which?

Most non-standard extended keys are for things like turning the computer off (or entering a sleep state), starting web browsers and email clients, starting and controlling a media player, etc, and should be handled by the GIU or keyboard driver and either not sent to any application or not always sent to the application that currently has keyboard focus.

If a keyboard has keys that can't be handed by the "keyboard configuration file" (i.e. a file that contains the scancode translation and possibly other information), then you could write a utility to sit between the keyboard and the rest of the system (where the input method editor would normally plug-in).

EDIT: I'm also going to make a full screen game library later, which will need to know the keyboard scan codes. Most of my OS is designed to be expandable. The mouse driver doesn't store the X and Y position of the cursor, that's the GUI's job. The mouse driver just returns how much to offset it by, so in my game library you can read this offset directly, and not worry about if the mouse cursor has hit the edge of the screen and the player can't turn anymore. And the game library has direct access to the screen buffer in full-screen, that way screen drawing calls don't have to pass through my GUI messaging system (program->GUI->driver->buffer like other programs do).

Unfortunately game programmers aren't as clever as they think they are - most game programmers still can't figure out that you don't need to waste 100% of CPU time constantly updating video when nothing on the screen is changing (e.g. game paused)...

If Bill Gates wanted to alt+tab between different 3D games he'd probably run out cash before he found games that actually allows a multi-tasking OS to do multiple tasks correctly. Part of the problem is that Windows is dumb enough to let these game programmers have (almost) direct video access (and 2 pieces of software can't both have full control of the same piece of hardware).


Cheers,

Brendan

Brendan wrote:Unfortunately game programmers aren't as clever as they think they are - most game programmers still can't figure out that you don't need to waste 100% of CPU time constantly updating video when nothing on the screen is changing (e.g. game paused)...

This reminds me of all my friends that are like "OMG.. 500 FPS" when looking at a static scene in a game that isn't changing..