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

[Steven Smith <sos22-xen@srcf.ucam.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2009 bytes --]

> >First: I now agree with you that scancodes are a better choice than
> >keysyms, and that I was wrong initially.
> The problem with scancodes is that you cannot always get scancodes from 
> the viewer.  You can get scancodes from SDL but you can only get keysyms 
> from VNC.  We would have to map VNC keysyms (which are just Xk keysyms) 
> to scancodes?
Yeah.  That's going to be a problem, and that's why I initially wanted
to avoid this approach, but I can't see any sane way around it.  The
mapping table you've got there at the moment is a pretty reasonable
first step, even if it is limited to a US keyboard layout.

We could potentially do a bit better if we go with the pushing keymaps
across xenbus thing, in that we can just send over a keymap which can
generate every possible keysym using compose keys and so forth, but
it'd be pretty distasteful.

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

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.

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel