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

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

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

> >> If the SDL viewer is using X11 configured with french keyboard, and the virtual
> >> machine is configured with US keyboard, the used keymap will be the US one. So
> >> when I press 'A' on my keyboard I will have 'Q'.
> > That kind of sucks.
> There is no way around that.

> > Not being able to produce every character sucks
> > more, but having to configure the keymap in every VM isn't much
> > better.
> 
> For sane i18n kbd support some translation must be done.
> 
> Make the guest think he has an US keyboard and do the translation on the
> host isn't going to work.  An US keyboard hasn't an 'Ä' key for example,
> so you wouldn't be able to type that character.
> Also some characters
> are arranged in a different way, for example on a us keyboard you have
> ';' and ':' sharing one key, whereas on a german one ';' lives together
> with ','.  That isn't going to work with host-side translation too.
Alright, I'm convinced: we need to send scancodes rather than keysyms,
since that's what input core's expecting and there's no sane way to do
the reverse mapping.

Perhaps the protocol should include some means by which the backend
can tell the frontend to use a particular keymap?  Pushing that
through to X is going to be a pain, but getting the console keymap
shouldn't be too bad.  It'll get more fun when we support multiple
frontends in a domain, but that's a problem for another day.

Someone also needs to think about what the vnc backend's going to do,
since it receives X keysyms rather than scancodes from the client.

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