Hide Forgot
Description of problem: When remotely displaying a X11 gtk-vnc session on Mac OS X from RHEL6 the keymap is broken and can not be used to interact with the VNC session. Version-Release number of selected component (if applicable): gtk-vnc-0.3.10-3.el6.x86_64 How reproducible: 100% reproducible Steps to Reproduce: 1. install libvirt/qemu-kvm and create a guest with VNC 2. remotely connect to the host OS with ssh w/ X forwarding (-X/-Y) from a Mac OS X X11 session 3. run virt-manager 4. connect to the console of your guest and you can type but the keys are mapped all wrong Actual results: Inability to interact with the console using the keyboard. Expected results: Able to interact with the guest OS with the keyboard. Additional info: This seems to be fixed upstream in 0.4.2 specifically in this commit, http://git.gnome.org/browse/gtk-vnc/commit/?id=e0910397d6ba1eca3d968c98a2105c1a7ead7fd7
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Workaround: Shutdown VM(s) Open XML file for the related vm(s) in /etc/libvirt/qemu/ add "keymap='en-us'" without " " into the line that begins with <graphics /> (change en-us for other keymaps) restarted libvirtd to reload xml file
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
NB, while this problem is fixed upstream in 0.4.2, backporting it to the RHEL-6 version of gtk-vnc involves non-negligible risk, due to major code refactoring that took place upstream between the version RHEL-6 is shipping & the version containing the fix. As such the fix is not something that is desirable to backport to the RHEL-6 version of gtk-vnc.
customer ran into this problem on the following windows 7 exceed for x windows server, and putty to create the ssh x11 tunnel this bz is tied more to to mac os, but not sure if the solution is generic in coverage for things like hummingbird exceed Maybe good to test common windows xservers. - hummingbird exceed - cygwin (definetly should test this one) Adding needinfo to ask if the upstream fix provides generic coverage for windows x11 servers.
The upstream rewrite has provided a framework to allow us to easily support multiple different platforms. It has code to support Cygwin's XWin X11 server, but I've no information about exceed, so can't say whether that would work or not. It all depends on how the X server has decided to map the Windows keycodes, which is sadly different for almost every impl.
Closing because per comment #8, the code changes involved in fixing this problem upstream are not reasonable to backport to RHEL-6 at this point in its lifecycle, nor is a rebase likely.