This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]

Steven Smith wrote:
I'm a bit surprised here. If we generate a KEY_Q event in Linux that may show up as a KEY_A key? There are keysyms for all the extended keys I thought.
I'm glad I'm not the only one who finds this confusing. :)

And I've been trying to figure this out longer :-)

The KEY_ constants in linux/input.h are a lot closer to scancodes than
to traditional X-style keysyms.  This becomes obvious once you notice
that there's no KEY_COLON, and there's only one KEY_A rather than a
KEY_A and a KEY_a.  While there is some small amount of normalisation,
so that you can mostly use the same keymaps for (say) AT and USB
keyboards, input core key events are best thought of as scan codes.
Calling them KEY_A etc. is more than a little bit deceptive, since
they actually refer more to places on the keyboard than actual

Okay, I didn't realize the KEY_ constants weren't keycodes.

I guess we're stuck using a keymap :-/


Anthony Liguori

The actual key mapping is implemented in drivers/char/keyboard.c (look
for key_maps), and we're going to have to go through that whether we
want to or not.

Of course, I completely failed to understand what was going on here a
couple of days ago, so there's a decent chance I've failed to
understand this time as well.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>