OSDev.org

Hey,
I've been writing a keyboard driver for my operating system, TachyonOS, to add functionality and free myself from BIOS-based drivers.

I did some research in several PS/2 articles on the OSDev Wiki, I've read the pages on the PS/2 controller and the PS/2 keyboard. It seems fairly simple in principle, however I am a little unsure on a few aspects of keyboard scan code sets and googling has not provided me with anything useful.

I want to make an array that keep track of which keys are pressed so programs can simply check it a key is pressed. I'm planning to use keyboard scan code set two. I like code set one much better but according to the article only set two is supported on all keyboards. It's too bad, set two looks like IBM purchased it from a bunch of monkeys with typewriters.

Anyway, I have a few questions.

• In the translation section of the PS/2 article it warns that with key code translation enabled it is impossible to know whether you are receiving data from the original device or the translation. However I think that BIOS operates with translation enabled and uses the translated values because it returns key codes from set one. How does it "know" which values to collect?
• To keep backwards compatibility I want to make sure programs can still read keys through BIOS. Would simply translating the key press from set two into set one and placing it into the BIOS keyboard function with INT 0x16 AH=05 be sufficient to emulate this?
• I can't seem to find the values for the "super" and "menu" keys on the key set. By these I mean the windows flag and the picture of a list with an item selected, respectively. Are they called something different or am I missing something?
• The "break" key has no key release event. I'm not sure how to register when it is pressed. Would it be a good idea to count it as 'held' and release it on a time delay?

Thanks for your help.

I think that BIOS operates with translation enabled and uses the translated values because it returns key codes from set one. How does it "know" which values to collect?

The BIOS actually initialized the PS/2 controller along with the chipset, and of course it knows what state it left it in. It will typically not like you changing it though.

Any legacy apps will be expecting scancode set 1 though.

To keep backwards compatibility I want to make sure programs can still read keys through BIOS. Would simply translating the key press from set two into set one and placing it into the BIOS keyboard function with INT 0x16 AH=05 be sufficient to emulate this?

You too, young padawan, must learn not to stash hack on hack. You can just as well port DOSBox while you're at it. Besides, you have no idea what direct accesses the BIOS might try to make to the PS/2 controller.

I can't seem to find the values for the "super" and "menu" keys on the key set. By these I mean the windows flag and the picture of a list with an item selected, respectively. Are they called something different or am I missing something?

In the first list that popped up, they're called the "GUI" and "APPS" keys. Also -1 to you for not trying and recording the scancode sequence yourself.

The "break" key has no key release event.

It actually has as far as implementations are concerned. Just look at the actual numbers being sent: you get the +0x80 for the release as usual. You just won't be able to establish a key hold.

Combuster wrote:

I think that BIOS operates with translation enabled and uses the translated values because it returns key codes from set one. How does it "know" which values to collect?

The BIOS actually initialized the PS/2 controller along with the chipset, and of course it knows what state it left it in. It will typically not like you changing it though.

Any legacy apps will be expecting scancode set 1 though.

Interesting. I will be disabling the translations system so the output makes a bit more sense. I support I'll have to reset the controller before hooking the table then, just in case it is half way through a sequence. Is there another way to get everything realigned?

I could do another table to find the scan codes.

Combuster wrote:

To keep backwards compatibility I want to make sure programs can still read keys through BIOS. Would simply translating the key press from set two into set one and placing it into the BIOS keyboard function with INT 0x16 AH=05 be sufficient to emulate this?

You too, young padawan, must learn not to stash hack on hack. You can just as well port DOSBox while you're at it. Besides, you have no idea what direct accesses the BIOS might try to make to the PS/2 controller.

Good point. Maybe I could write my own handler for INT 0x16. Would that be a more optimal solution? Should I just ditch legacy compatibility?

Combuster wrote:

I can't seem to find the values for the "super" and "menu" keys on the key set. By these I mean the windows flag and the picture of a list with an item selected, respectively. Are they called something different or am I missing something?

In the first list that popped up, they're called the "GUI" and "APPS" keys. Also -1 to you for not trying and recording the scancode sequence yourself.

Ah, thankyou. I suppose I could have just polled BIOS's code set one strokes and looked them up but I didn't think of that.

Combuster wrote:

The "break" key has no key release event.

It actually has as far as implementations are concerned. Just look at the actual numbers being sent: you get the +0x80 for the release as usual. You just won't be able to establish a key hold.

Looking at the table again I can see that it actually does send a release code of 0xF0, 0x77 but it happens as soon as it's pressed. If there's no hold then programs won't be able to check for it. I know that Ctrl+Break should generate interrupt 0x1B. Is it actually needed for anything else? Could I just ignore it?

Also, Would I be correct in assuming all key releases are the same as the press values but they have 0xF0 before them or after 0xE0?

Thanks for your fast reply and all your help!

Prochamber wrote:Should I just ditch legacy compatibility?

Look who's slapping Brendan in the face and then going along with his idea...

m12 wrote:Look who's slapping Brendan in the face and then going along with his idea...

I'm assuming you mean this thread.
As I was aware Brendan was mostly arguing with me about protected mode and memory allocation. You can PM me rather than posting about this.

Prochamber wrote:

m12 wrote:Look who's slapping Brendan in the face and then going along with his idea...

I'm assuming you mean this thread.
As I was aware Brendan was mostly arguing with me about protected mode and memory allocation. You can PM me rather than posting about this.

I think your argument about

Brendan wrote:lame pieces of puke

was more intense than that. But let's not restart the flame war.