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

[Anthony Liguori <aliguori@xxxxxxxxxxxxx>]

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