Selecting "same as host" for keymap doesn't really select the host keymap

Bug #348364 reported by Thierry Carrez on 2009-03-25
This bug affects 2 people
Affects Status Importance Assigned to Milestone
virt-manager (Fedora)
Fix Released
virt-manager (Ubuntu)

Bug Description

Binary package hint: virt-manager

Virt Manager now allows you to select a keymap for the display device.

By default, "same as host" is selected. However on my system (locale fr_FR) it ends up selecting "en-us" in that case. I have to remove the display, create a new one, uncheck "same as host" and manually enter "fr" to get the right keymap.

I suspect some conversion from fr_FR -> fr failed and "en-us" gets picked up as a default choice ?

Related branches

Description of problem:
I have created two virtual machines with virt-manager:
- Windows XP (32bit)
- Fedora 10 (64bit).
Both installed without problems, but when I try to make any text input in either of the guest OS, I get a strange, 'qwertyu' type keyboard layout.

On the host, I am using KDE 4.2, a German keyboard (evdev-managed) with DE layout. Changing keyboard model from edev-managed to Generic doesn't make any noticeable difference.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create virtual machine with virt-manager
2. Start guest from virt-manager
3. Enter text in guest

Actual results:
Unexpected keyboard layout of unknown type, unusable

Expected results:
German 'qwertzu' keyboard layout

Additional info:
1. Whenever I switch the keyboard layout to "US" on the host, I immediately get a layout on the guest which is nearly ok (no symbols obtainable with the AltGr key); when I switch back to "DE", the borked layout is back.

2. When I run any of the guests with the qemu-kvm command, I get a guest layout which is nearly ok as well.

There is a workaround:

1. Change a line in the virtual machines's XML file in /etc/libvirt/qemu/ from
<graphics type='vnc' port='-1' autoport='yes' keymap='en_us'/> to
<graphics type='vnc' port='-1' autoport='yes' keymap='de'/>

2. Restart the libvirtd daemon.

But a bug in virt-manager remains. This tool seems to be made for virtualization newbies like me who usually don't poke around in xml configuration files hidden from ordinary users. It would be preferrable if virt-manager asked for the desired keymap.

I still have the AltGr problem mentioned above, but that is another story.

QEMU has had a VNC extension added so that the keymap is no longer required - it will use raw scancodes across the wire & into the guest, so the guest has complete control over keymap without needing this setting. This will be in Fedora 11

Thanks, Daniel,
that sounds good (as far as I can understand it), and I can wait until Fedora 11 comes up.

Danpb, so how will this work? Does qemu just ignore a manually specified keymap, or should libvirt drop the keymap setting for a sufficiently new version?

No, if you set a keymap, QEMU will always use that keymap. The raw scancode VNC extension is only activated if no keymap is specified. So I'd recommend that virt-install never set a keymap, unless the user explicitly asks for one with "--keymap fr". For virt-manager we should probably have a globall preference available, which defaults to no keymap at all, but which lets the user override to an explicit one if desired (eg, so it works with VNC clients not supporting the extension)

FWIW: If there is no keymap specified in the xml file, i. e. if the above line reads
<graphics type='vnc' port='-1' autoport='yes'/>
then the host's keymap setting are respected, even the characters accessible by means of the AltGr key are reproduced. It seems as if the key codes are mapped directly to the guest.

But you can't set this in virt-manager, you have to make changes in the xml file manually.

Okay, fixed python-virtinst-0.400.3-5.fc11 (rawhide). Now the user has to explictly set a keymap via virt-install, or when adding a Graphical device via virt-manager.

Closing as RAWHIDE. Please reopen if you still see issues.

Jonathan Gibert (jokot3) wrote :

According to redhat bugtracker, this issue is fixed in version python-virtinst-0.400.3-5(.fc11)

see :

Jonathan Gibert (jokot3) wrote :

PS : workaround :

- launch virsh
- type "edit <your_dom_or_machine_name>" (this allows you to edit the xml config file of the guest)
- locate the line "<graphics type='vnc' ..." and remove any reference to "keymap"
- the line should look like this : <graphics type='vnc' port='5900' autoport='yes' listen=''/> with default config
- vnc will now use the host keymap by default minus the "AltGr+" key

Thierry Carrez (ttx) on 2009-04-22
Changed in virt-manager (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Changed in virt-manager (Fedora):
status: Unknown → Fix Released
Marc Deslauriers (mdeslaur) wrote :

This issue has been fixed in virt-manager in Lucid.

Changed in virt-manager (Ubuntu):
status: Confirmed → Fix Released
Cock Roach (cockroach) wrote :

No, it ain't fixed.
Now, I have a us-en keyboard, but all the keys have MOVED UP 1 ROW!
So 5 is r, 0 is o, 6 is t and so on.....
This 2.6.35-25-server on Ubuntu 10.10.

Does anyone know how to move the keys back down 1 row, it is real hard to type like this :(

Goutham (kgouthamk) on 2011-05-04
Changed in virt-manager (Ubuntu):
assignee: nobody → Goutham (kgouthamk)
assignee: Goutham (kgouthamk) → nobody
Changed in virt-manager (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.