A proposal of how to improve keyboard event handling

[Laurent]

AZERTY gives me 24-29. So apparently I was right, scan codes refer to the physical location of the key, not to its meaning.

[SoleSoul]

Oh , cool!
The keys a,z,e,r,t,y give you 24-29?
On my keyboard, the numbers 24-29 are produced by the keys q,w,e,r,t,y. So indeed you were right. Interestingly, if games were using keycodes for wasd movement you could have played them on your azerty keyboard without any problem.

One more thing we should check, if you ask X to convert the code 24 to keysym what would be its output? 'q' or 'a'? On qwerty it is converted to 113 which is 'q'.

So how do we go on from here? We have to think some more.

There is one thing that should not be forgotten. For a given physical keyboard layout, there should be a way to get the code of a specific key regardless of the current language or modifier keys. I am talking about the event.key.code. The current situation where shift+1 is translated to '0' can be improved if we use keycodes for this purpose.

I have to think a bit. Maybe there is a good solution for everything including different physical layouts although I doubt it because if it was simple why games don't implement it.

[Laurent]

One more thing we should check, if you ask X to convert the code 24 to keysym what would be its output? 'q' or 'a'? On qwerty it is converted to 113 which is 'q'.

I guess X uses the current keymap/layout/locale/whatever, and thus on my AZERTY keyboard 24 would be 'a'.

[Hiura]

Just remember something... Maybe it can help us here.

When I wrote sf::Keyboard implementation for Mac OS X I had to play on the USB level.

Down there I managed to get the "usage" property of a key. It is used to identify a key on a standardized keyboard physical layout, ie. it does not depend on the character printed on the keys nor on the OS' interpretation of the keys. Here is a relevant comment in Apple HID API (IOHIDUsageTables.h) :

/* KeyboardOrKeypad Page (0x07) */
/* This section is the Usage Page for key codes to be used in implementing a USB keyboard. A Boot Keyboard (84-, 101- or 104-key) should at a minimum support all associated usage codes as indicated in the “Boot” */
/* column below. */
/* The usage type of all key codes is Selectors (Sel), except for the modifier keys Keyboard Left Control (0x224) to Keyboard Right GUI (0x231) which are Dynamic Flags (DV). */
/* Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate otherlanguages. */

Once I got these USB "usage" keycodes I convert them into "virtual" keycodes which have the same meaning. They differ only on their values. (I guess it's because the first keyboards didn't have USB.) These "virtual" codes are issued from the ANSI-standard US keyboard.

Then I used an OS based function to convert these "virtual" keycodes to their localized value.