Bug 188552 - vino doesn't cope with differences in keyboard layout between client and server
Summary: vino doesn't cope with differences in keyboard layout between client and server
Alias: None
Product: Fedora
Classification: Fedora
Component: vino
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-11 03:37 UTC by Alexandre Oliva
Modified: 2013-03-06 03:45 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2008-08-12 04:30:31 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2006-04-11 03:37:13 UTC
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):

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.

Comment 1 Alexandre Oliva 2006-04-11 03:44:10 UTC
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.

Comment 2 Zachary Napora 2008-04-20 20:44:30 UTC
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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Note You need to log in before you can comment on or make changes to this bug.