Description of problem: Various keys, most notably "(" and ")" cannot be typed in virt-manager guests when connecting over VNC with the standard Gnome "Screen sharing" option (vino-server). I have tested this with Fedora 25 and Ubuntu 14/16 guests, and with two different VNC client (Apple Screen Sharing and TightVNC on Windows), so I believe the problem is really with the vino + virt-manager combination. Version-Release number of selected component (if applicable): Fedora 25 host vino 3.22.0 virt-manager version 1.4.0 Ubuntu 14.04, 16.04 and 16.10 guests Fedora 25 guest How reproducible: Always Steps to Reproduce: 1. Create a guest with default configuration from ISO image (e.g. Ubuntu or Fedora) Default configuration has QXL video driver. 2. Wait until the guest booted, and launch a terminal or select any text entry dialog 3. Type, directly on the host, all characters from left to right on the first row of the keyboard, while holding shift (i.e. shift 1234567890). You should see !@#$%^&*() 4. Make sure that Gnome screen sharing is active 5. Connect to the host with a VNC client, e.g. TightVNC on Windows 6. Type the same sequence in the VNC window. Actual results: From VNC, you get !@#$%^&*. Expected results: The same as in the host: !@#$%^&*()_ Some other keys may be missing too, but they are from an extended european keyboard layout. For example, the top-left gives me ` natively, but nothing through VNC. Additional info:
To stand any chance of it working, you need to make sure your local desktop keymap 100% matches the keymap being used by the VINO server, and also matches the keymap used by the guest OS desktop. Any of these don't match and you'll certainly get incorrect keys pressed. Even when they are all set correctly matching some things may still break. The VNC keyboard message protocol is fundamentally doomed because it works by sending X11 keysyms, which are a lossy encoding of the original hardware scancode, controlled by the keymap. GTK-VNC (used by virt-manager) & QEMU both support a VNC extension that sends encoded XT scancodes over the wire instead of X11 keysyms, so as to avoid the lossy conversion & be independant of keymap. This works well if running virt-manager locally, but if you run VNC to get to the desktop where you run virt-manager you're negating the benefit of this extension to a large degree as the local desktop -> VINO part has already done the lossy encoding. Best you can do is try to ensure the keymaps match at every point. If that doesn't make it work, then you'll just need to take VNC client & VINO out of the loop and directly interact with virt-manager.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.