Hello Gerhard, On Thu, Mar 08, 2012 at 06:54:46AM +0100, Gerhard Wiesinger wrote: > I'm having also isssues with german keymappings. > > E.g. Under DOS when pressing shift keys will always be uppercase. > Also ALT-GR doesn't work.
If I start qemu with -k de and the layout in the Client OS is also set to de layout I can freely switch the layout in the VM and it works as expected (also key presses with shift & alt-gr). It also works if I'm using gtk-vnc which implements the QEMU extended keyboard events. I only tested it with Linux VMs. > I already discussed such issues here: > https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg02225.html > https://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00138.html Thanks for the links. I think our problem is a little bit different: We provide a VNC console for our customers. The customers use different keyboard mappings and they expect that the same character in the VNC window appears like on their local editor, if they press the same key. Thats not what QEMU does, because it emulates a keyboard controller and the VNC keysymbols must be converted to scancodes. The character that shows up in the VNC window further depends on the keyboard layout in the VM. So we are trying to minimize the problems with the vnc console that a customer could have. Our currents ideas: * Let the customer choose the "-k " parameter value for their VMs. - Keyboard layout change needs VM restart. - Wrong characters shows up if the customer uses a different layout on their Client OS. Not even all ASCII characters work, because on different layouts different meta-keys (shift, alt-gr) presses are necessary. It could be handled if QEMUs VNC server would interpret the received Keysymbol and add/remove additional needed keypresses. But QEMU doesn't do this. It also would be an ugly hack if u expect that it should behave like a virtualized keyboard controller. (Idea from my first post) - Sometimes administrators which different Keyboard layouts have to use the same console => leads to problems * Use a VNC client which supports QEMUs extended keyboard events. - Customer didn't expect that he have to choose the keyboard layout in the VM. If he has a different layout set in the VM he wonders why different characters show up than on their local applications.. - Works with gtk-vnc, but we need an OS independent Java Applet. The JVM didn't know the keycodes so we would have to translate the java keysymbols to keycodes. For this we have to know the keyboard layout on the Client OS, which afaik we also can't detect in the JVM. We could guess the keyboard layout on the basis of the locale setting but this can also led to new problems. o Best idea currently: Let the user choose in the applet their local keyboard layout, use this for conversion and try to inform them that the layout in the VM has to been choosen. I'm glad for every hint for a good solution. BTW: Sorry for the duplicate posts. I was wondering why I didn't receive my own ML post. It turns out that gmail is moving own ML posts directly to the archive. :) regards Fabian