| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
characters.
Okay, I didn't realize the KEY_ constants weren't keycodes.
I guess we're stuck using a keymap :-/
Regards,
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.
Steven.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home