This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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


Attachment: signature.asc
Description: Digital signature

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>