GNOME Bugzilla – Bug 353304
using Alt-Gr from a Windows VNC client to vino
Last modified: 2007-11-09 11:08:26 UTC
(Sergey: I'm cc'ing you on this because I think the answer is going to turn out to be "you need to make vino use xkb", and I figure you'd be able to confirm or deny that.) When using a Windows client (eg, www.realvnc.com, although as far as I can tell, all existing Windows VNC clients derive from the same codebase and have the same behavior), Alt-Gr works differently from how it works with a Linux client (eg, tightvnc). If you do this: 1. press Alt-Gr 2. press e 3. release e 4. release Alt-Gr from a linux client, then vino sees exactly that series of keypresses and releases (press XK_ISO_Level3_Shift, press XK_e, release XK_e, release XK_ISO_Level3_Shift). But if you type those keys from a Windows client (with an appropriate keymap, say French), vino sees: 1a. press XK_Control_L 1b. press XK_Alt_R 2a. release XK_Alt_R 2b. release XK_Control_L 2c. press XK_EuroSign 3a. release XK_EuroSign 3b. press XK_Control_L 3c. press XK_Alt_R 4a. release XK_Alt_R 4b. release XK_Control_L The first oddity is that Alt-Gr gets translated to Ctrl+Alt; apparently they are entirely equivalent on Windows. Vino doesn't recognize this, though it turns out to not matter in this case because of the second oddity, which is that when you actually type an Alt-Gr-ified character, it fakes releasing Alt-Gr and then sends the translated keycode rather than the raw one. Vino doesn't cope with this, because it assumes that any non-latin1 keycode it receives can be typed directly without needing any modifiers. I started out trying to fix this by making global_input_data.keycodes and .modifiers into GHashTables, and storing non-latin1 keycodes in them too. But then I ran into a second problem, which is that vino assumes that Alt-Gr is modifier 2, which isn't true for all layouts. (Eg, in the default French layout, Alt-Gr seems to be 4, and Shift+Alt-Gr is 5.) And this is the part that I think we need xkb for; I don't think there's any way using only core xlib to reliably figure out what modifier keys we need to fake pressing in order to get a given keycode. I'm continuing to hack on this for now, but any confirmation / contradiction / hints / whatever would be appreciated. (downstream bug is 196556 at bnc, but it has customer data so it's not public)
Created attachment 72793 [details] [review] patch to use xkb and fix windows i18n interop issues OK, this patch: 1. Adds support for XKB (while retaining core keyboard support as a compile-time or run-time fallback). 2. Recognizes that Left-Ctrl + Right-Alt means Alt-Gr and translates accordingly 3. Deals with receiving Alt-Gr-ified keysyms from the client rather than receiving Alt-Gr + base key. 4. Deals with decomposing keysyms like XK_ecircumflex if they can't be typed directly, but can be typed using a dead key 5. Removes the restriction to Latin1 keysyms. (Tested with Greek and Cyrillic.) 6. Handles multiple keyboard groups (watching the current group on the server, latching groups as needed to type out-of-group keysyms from the client). 7. Watches for and handles keymap changes under xkb. (I didn't add the code to do this under core X as well.)
Comment on attachment 72793 [details] [review] patch to use xkb and fix windows i18n interop issues hm... there are still some problems with this patch
Created attachment 79003 [details] [review] patch to make vino use xkb The patch here got really big, so I'm going to resubmit it in pieces to make it easier to review. Part 1 is xkb support (if the server supports it), including full support for multiple keyboard groups, and watching for keymap changes. (The other parts will be: NumLock/keypad key support [currently vino doesn't take the server NumLock state into effect], making things like Shift+UpArrow work [currently if you type Shift+UpArrow on the client, vino turns that into plain UpArrow], and the windows-specific fixes [Ctrl+Alt <-> Alt-Gr translation, and decomposing composed characters])
Created attachment 79007 [details] [review] patch to fix numlock support
Created attachment 79008 [details] [review] patch to fix, eg "Shift+UpArrow"
Created attachment 79036 [details] [review] patch with just the windows fixes (Alt-Gr and precomposed chars)
Thank you for your work on this problem. I would just like to say that this bug is really bad for people who don't use US keyboards, for us many things are mapped with alt-gr. On my slovenian keyboard, I can't type the following through vino from a windows client: []{}@| it really makes programming a complete nightmare. So your work on this is really appreciated and i'd REALLY be VERY happy if that fix could go in 2.18...
PS: in waiting for that bug to be fixed in vino... can you just tell me if you know of another linux VNC server that would properly deal with alt-gr from windows clients? i really need that feature...
This bug was reported in Ubuntu too: http://launchpad.net/bugs/34805
And on debian too in addition to ubuntu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407805 Note that vnc4server does not have the problem. Any chance Dan Winship patches will be integrated?
now that vino has branched for 2.18, can I commit this to HEAD so it gets lots of testing before 2.20?
Dan, please, go ahead and commit. We'd love to test it.
It's such a pity that this great patch is not in the code right now. I applied it today (against r484) and it worked really great! I'm so happy about my @ ;) Well, r484 is pretty old (Dec 2006) and my C++ is not good enough to integrate this patch into the latest revision. Please, PLEASE add this patch to HEAD, you would make the life of so many people easier. Thanks. Great work! ;) Tobias PS: applied all patches provided here starting with attachment 79003 [details] [review] (patch to make vino use xkb), the patch before this one I left out because of Dan's comment about it.
I've merged Dan's patch into HEAD. But before commit, i'd like to do some tests. I created a package for Ubuntu Gusty. Please, test and tell your impressions. For those who aren't running Ubuntu Gutsy, there is also a tarball (.tar.gz) available. Check out: http://www.gnome.org/~jwendell/code/ Thanks.
Hi, compiled your package today on Fedora 7 and it worked perfectly. However, for everything to work I have to change a setting (either with your package or with my patched r484): I had to change the keyboard setting, namely the "ALT/WIN key behaviour" - I had to change it from "default" to "Alt and Meta are on the Alt keys (default)." I used the keyboard indicator applet to do this. For me, this is perfectly okay, but for people who just want VNC sessions to work this might be not trivial. Thanks again Tobias
OK, commited. Thanks, Dan.
OK, my problems with having to switch keyboard settings is gone. But I have another problem: with Dan's package, I cannot use SHIFT+TAB, it behaves like just pressing TAB. That's just a minor problem, but I guess the fix will also be trivial. Thanks, Tobias
(In reply to comment #17) > I cannot use SHIFT+TAB, it behaves like just pressing TAB. Build vino with "--enable-debug" (you don't need to "make install"), and then: 1. Run vino-preferences and turn off "Allow other users to view your desktop" 2. killall vino-server 3. In the build tree, run VINO_SERVER_DEBUG=input ./vino-server --oaf-activate-iid=OAFIID:GNOME_RemoteDesktopServer >& vino.log (that's all one line, bugzilla will probably wrap it) 4. Run vino-preferences and turn "Allow other users to view your desktop" back on. 5. Connect to the machine from another machine, press Tab and then Shift+Tab, then disconnect 6. ^C the vino-server and attach the log to this bug, along with the output of "setxkbmap -print"
Created attachment 95918 [details] the log Dan requested vino.log created exactly as Dan told me to
setxkbmap -print xkb_keymap { xkb_keycodes { include "xfree86+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc(pc105)+de" }; xkb_geometry { include "pc(pc105)" }; };
Hm... ok, the problem is that the server side (the machine running vino) considers the Tab key to have two different keysyms on it (Tab and ISO_Left_Tab respectively), whereas the client side considers it to only have one keysym on it, and so expects Shift+Tab to be treated the same way as Shift+Up Arrow. (I assume the client is a non-Linux box?) I don't think there's a "clean" fix for this; the client and server are both behaving reasonably, this is just one of those warts in the protocol. The only way to fix it would be to special-case the Tab key in the code. If you want to suggest doing that, you should probably file a new bug (and refer to the comments in this one). You can work around the bug by running xmodmap -e 'keycode 23 = Tab' (on the vino box). This doesn't seem to interfere with ordinary gtk operation, so it's probably safe to do this all the time. (Eg, putting 'keycode 23 = Tab' into ~/.xmodmap or ~/.Xmodmap or something might cause it to automatically be evaluated, depending on your distro)
yes, correct, client is the realvnc viewer on windows xp. What do you think is the cleanest solution? I mean, I use win xp for the client because I need my notebook running xp for the university stuff. But I vnc from that to my machine at home, which is running linux. I guess this is a pretty common setup? I can of course use the hack that just works for me, but wouldn't it be good to fix that for everyone else? Would it make sense to request what you suggested? ("special-case the tab key in the code") Thanks for your help! Tobias
*** Bug 317169 has been marked as a duplicate of this bug. ***