Red Hat Bugzilla – Bug 188552
vino doesn't cope with differences in keyboard layout between client and server
Last modified: 2013-03-05 22:45:32 EST
Description of problem: Using the VNC server loaded directly into X, if I connect a VNC client to that server, keyboard events generated on the client are sent to the server, and interpreted by the server, in such a way that the keyboard layout of the client is respected, e.g., the local configuration of the X server on the vnc server side is pretty much disregarded as far as the client is concerned, and all that matters are its own local configurations, which is arguably the way things should work. vino doesn't work that way, unfortunately. It manages to combine in very odd ways the differences between the client's and the server's keyboard configurations. For example, if the server is configured for BR-ABNT2 layout while the client is configured for US with dead keys, the dead keys are all wrong and multiple keys in the '[] area generate ], rendering the VNC session nearly useless for programming. Version-Release number of selected component (if applicable): vino-2.13.5-2.2 How reproducible: Every time Steps to Reproduce: 1.Set up a vino server with gnome-keyboard-properties set to the BR-ABNT2 layout 2.Set up a client with gnome-keyboard-properties set to US with dead keys 3.On the client, out of the VNC session, on say a gnome-terminal, understand how the accent keys (`, ~, ', " and ^) are supposed to work (hint, follow them by blank or repeat them). Also verify that the [ and ] keys work without change. 4.Try to write some C or shell code over the VNC session, on a remote gnome-terminal, using characters such as `, ~, ', ", ^, [ and ] Actual results: 3 is fine (as long as you don't trip into scim bugs :-), but 4 is impossible Expected results: keystrokes should ideally produce the same results, like it does if you connect to the vnc server built into X. Additional info: It might be easier to test this mis-behavior on FC5 than on devel, since the latest X crashes with vnc loaded and recent scim changes are introducing a great amount of impredictability as far as keyboard configurations are concerned.
Additional steps to Reproduce (or to figure out what I'm after, and how that might be possible): 5.Set up the server as an Xvnc server (add Load "vnc" to xorg.conf and restart the session) 6.Connect from the same client to the Xvnc server and try again, you'll see everything works as if the server was configured with the client's keyboard configuration. Or so it seems to me.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.