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

[Anthony Liguori <aliguori@cs.utexas.edu>]

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.
>