[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. Steven. Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |