Is it possible to obscure or eliminate PS/2 scan codes?

[MilkyGirl]

I am writing a PS/2 keyboard driver now, and I notice that most OSes seem to map scan codes to ASCII equivalents used in writing.

However, I'd like to re-map and assign certain bytes from the scan codes to different symbols to appear on the console.

For example, I'd like to press "6", but want "3" to come out on the screen(Not that it makes sense, but that's for the example).

What I want to do is map certain scan code bytes sent from the PS/2 serial interface of the keyboard, change their assigned scan code meanings, and re-map them to different values.

EXAMPLE:

Say I write a game that will run on my text-based kernel (ASCII game, if you will), and in this game I want to press "SPACEBAR", which should be 0x39, but I want the hex equivalent to assign its scan code to "P", which is 0x19, and then map the value to its appropriateness for the game's state.

[Combuster]

It's called a keyboard layout.

The numbers you get from the PS/2 controller correspond to physical /locations/ on the keyboard, there's no character info involved.

[MilkyGirl]

I know that, but if you could please re-read my question after I edited above, could you then re-edit or reply as necessary to fill my question?

I want to re-map scan codes from one key to another, and then use that value input as necessary.

[Combuster]

Either you can't think or you can't talk. Pick one.

The answer I posted is still valid given the question.

[iansjack]

If I understand you correctly, you want the keys to produce one value usually (the normal value), but produce different values within a particular program. I don't think this is an OS issue; can't your program do the remapping, translating characters as it receives them?

[Mikemk]

What are you trying to do? Map the scan codes to a specific character, then map that character to a different character? That doesn't make much sense...

[kohlrak]

AFAIK, you can't remap the scancodes. The scancodes usually translate to ASCII, but not all do, nor do they have to. The fact that they do convert easy is for convenience. If you want to make them mean something else, there's nothing to stop you from making a replace table or something (make a table of 256 bytes and use the scancode as an offset into the table). Doing that, all you have to do is set each byte in the table to whatever you want it to be.

[egos]

Yes, in first stage my keyboard driver only posts event identifier, virtual key code and some flags:

Even more generalized way is to use event queue for foreground process. For keyboard I use KEYDOWN and KEYUP events with following parameters: event identifier (dword), virtual key scancode (dword), control key flags (dword: low byte - left, next byte - right), keyboard indicator flags (dword).

When application recieves event package it can translate the package by self or pass this package and required key map selector back to the driver.

[rdos]

You generally have some type of table per national keyboard layout that translates scan codes into something OS-specific. Translating to pure ASCII is not a good idea, unless your only aim is text-mode, as GUIs require more specific key information than just ASCII-code. If I did this from scratch today, I'd study the USB HID key definition, and unicode, and make up some new translation using a unicode/HID mixture.