Keyboard driver: Scancode questions

[CRoemheld]

Hello,

I have two questions about scancodes when implementing a keyboard driver.

While I was implementing a rudimentary keyboard driver, I noticed that two (maybe more, still about to find out) keys on my keyboard deliver the same scancode to my OS. Is there a way to distinguish them in this situation? (Additional informations: German keyboard layout, Laptop, the keys involved are the "3" from above the letters and the "Raute" (german), which is "#" (just left on the bottom half of the enter key)
-> Image to show: https://de.wikipedia.org/wiki/Datei:KB_Germany.svg

The second questions is: I have some keys on my keyboard which are considered to be "multi-character characters". Meaning I got keys that aren't represented in one, but two bytes (Ä, Ö, Ü, ß, ...). Now, if I were to press one of these keys, how do I read the bytes from such a character? Would I need to use something like

Code: Select all

/* Reads 2 bytes from port 0x60 */
uint16_t multichar = inw(0x60);

instead of

Code: Select all

/* Reads one byte from port 0x60 */
uint8_t singlechar = inb(0x60);

? Also, how would I know BEFOREHAND which size to read from the port?

Hope you can help me.

[Octocontrabass]

Is there a way to distinguish them in this situation? (Additional informations: German keyboard layout, Laptop, the keys involved are the "3" from above the letters and the "Raute" (german), which is "#" (just left on the bottom half of the enter key)

Those two characters are on the same key on a US English keyboard, so your hardware may be translating the key codes somehow. They can be distinguished by the shift state.

The second questions is: I have some keys on my keyboard which are considered to be "multi-character characters". Meaning I got keys that aren't represented in one, but two bytes (Ä, Ö, Ü, ß, ...). Now, if I were to press one of these keys, how do I read the bytes from such a character?

Scan codes are not characters. When scan codes are more than one byte long, you will receive one byte on each IRQ and you must keep track of previous bytes to determine which key is being pressed or released. Once you know which key it is, you can translate the key press into whatever data you want.

[SpyderTL]

There is a pretty big difference between key press events and characters on the screen.

The OS will be responsible for converting one to the other, but that is not a small task. I would recommend focusing on just the key press events first, and once you have that nailed down, then figure out what you want your OS to do when those events are handled.

Normally, your keyboard driver will do nothing until you get an interrupt or until a function is called. Then the driver will determine whether there is any work to do, or if it can go back to sleep.

If it determines that there is work to do, then it will read data one byte at a time (for PS2) or one packet at a time (for USB), and convert that data into events that the OS can understand.

For a PS2 keyboard driver, it needs to be able to read single or multiple byte events from the hardware, and convert that into a single event to pass to the OS. The details on how this works is on the wiki.

https://wiki.osdev.org/Keyboard
https://wiki.osdev.org/%228042%22_PS/2_Controller

Read section "Scan Code Sets, Scan Codes and Key Codes", which explains the process of converting key codes into key press events.

Also, notice in the Scan Code Tables at the bottom, multi-byte codes start with 0xE0, 0xE1 or 0xF0, and no single-byte codes start with these values, so you can use these values to trigger your multi-byte read logic.

Let us know if you have any other questions.

[CRoemheld]

Those two characters are on the same key on a US English keyboard, so your hardware may be translating the key codes somehow. They can be distinguished by the shift state.

True. Normally the would be distinguished by checking if the shift key was pressed, however on the german keyboard layout both keys are on a non-shifted position. So this wouldn't work in my case.

Scan codes are not characters.

Sorry, made a blunder in my original post, the function reading from the keyboard port should assign the value to a variable named scancode, not *char.

When scan codes are more than one byte long, you will receive one byte on each IRQ and you must keep track of previous bytes to determine which key is being pressed or released. Once you know which key it is, you can translate the key press into whatever data you want.

Okay, that seems understandable. Will try it.

Also, notice in the Scan Code Tables at the bottom, multi-byte codes start with 0xE0, 0xE1 or 0xF0, and no single-byte codes start with these values, so you can use these values to trigger your multi-byte read logic.

Same as Octocontrabass said: First fetch the first byte value, then determine if it belongs to a multiple-byte code or not.

Thanks a lot for your help!