Friday, February 27, 2009

VNC Shifty Keyboard Problems

I've described, in a previous post, the way I use x11vnc, vncviewer and ssh, to access the graphical desktop on my home PC from work. I have a rather similar setup for accessing my work PC desktop from home. But I rarely use VNC to access my own computers - I usually only need VNC to troubleshoot problems on my wife's Window$ PC. The combination of ssh, screen, and emacs -nw is usually sufficient for most of my own remote access needs.

So I haven't used VNC for a while, which is why I haven't noticed a major problem: the SHIFT key doesn't work. Well, actually it does work, but some keys cannot be SHIFTed - e.g. the combination of SHIFT and the slash (/) key, on my keyboard, should yield a question mark (?), but I get the slash instead.

I first hit the problem at work, upon accessing my home machine, but I didn't have time to delve into this so I let it go. I was rather surprised to be hit by the same problem that same night, but this time while trying to access my work PC from home.

I used xev on the remote machine to spy on the keyboard events that are sent to the X server by the remote VNC server, in response to keyboard events sent to it by the local VNC client. Oddly enough, when I hit slash with the SHIFT key pressed, xev printed out the expected question mark. This meant that the local keyboard events reached the other side unharmed.

I suspected that the problem is with the specific VNC viewer that I'm using (RealVNC), so I searched the Net for any SHIFT related problem that RealVNC users may have already reported. No luck - as far as I could tell, no one has reported or complained about the exact same problem that I had.

When I got back to work the next day I tried accessing my home PC with the TightVNC VNC viewer, and hit the same problem. OK, this meant one thing: the problem is with the VNC servers (I used x11vnc on both sides). I scanned the x11vnc manual page for any clue, and found out that it has quite a few command line options to handle all sorts of keyboard related problems and features. It looked rather hopeless. And then I found the flag -debug_keyboard, so I modified the x11vnc command line to look like this:
x11vnc -debug_keyboard -ncache 0 --forever -localhost -display :0 -rfbauth .vnc/passwd &

restarted the VNC server, connected again and typed a few question marks. I read the log messages in the remote ~/.xsession-errors, but it all seemed to be correct - i.e. the server got both the SHIFT and the slash, and logged a question mark key being pressed.

At this point I had no choice but to guess a combination of command line options that might fix my problem. Luckily, my first attempt paid off:
x11vnc -xkb -ncache 0 --forever -localhost -display :0 -rfbauth .vnc/passwd &

I can happily join the other monkeys now.

[08 Mar 2009] UPDATE: Karl J. Runge, the author of x11vnc, was kind enough to contact me directly in order to debug this issue. Thanks!

He directed me to add -dk -dk -o logfile to the x11vnc command line, both with and without -xkb.

It turns out that the real culprit is the gnome-settings-daemon which is also launched from ~/.xprofile. If it's not running x11vnc works like a charm. This must be a recent regression in gnome-settings-daemon.

Mr. Runge concluded that I'll have to stick with the -xkb command line option. Which is fine by me. It works.

38 comments:

  1. Did anything change on the machine just before the shift problem appeared? Maybe the Xserver got updated and the keyboard mapping was altered somehow that would only affect x11vnc's keysym insertion algorithm.

    If you run x11vnc with '-dk -dk' (no -xkb to begin with) you will get the full keyboard mapping and can perhaps look at what is happening. You'll also get more output when you type the problem keys.

    I'm interested in seeing the -dk -dk output; we can discuss it offline if you like.

    ReplyDelete
  2. It's quite likely that the Xserver got updated before I hit this problem. Then again, it's quite likely I have an updated x11vnc too...

    For reference: x11vnc reports that its version is 0.9.3 (package version is 0.9.3.dfsg.1-1), and X reports that its version is 1.4.2 (package version is 1:7.3+18).

    I tried '-dk -dk', with and without -xkb, and I get the following sequence of calls to XTestFakeKeyEvent when hitting slash and then shift+slash:

    ==== without -xkb (I get "//"):
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", down)
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", up)
    XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", down)
    XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", up)
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", down)
    XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", down)
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", up)
    XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", up)

    ==== with -xkb (I get "/?"):
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", down)
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", up)
    XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", down)
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", down)
    XTestFakeKeyEvent(dpy, keycode=0x3d "slash", up)
    XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", up)

    The first sequence looks wrong - note the extra shift up / shift down events when hitting shift+slash.

    My email is zungbang at gmail dot com, feel free to contact me.

    ReplyDelete
  3. I have the same problem, but I'm not running x11vnc; I'm using gnome's built-in remote desktop, called vino-server, and can only access the gui vino-preferences to control it, and no option made this shift problem go away... any ideas?

    ReplyDelete
  4. You may find some hints at Ubuntu bug 112955.

    Hope this helps.

    ReplyDelete
  5. My shift key problem appeared in a way that pressing the shift key or not didn't make any difference.

    At the example with ? and / xev showed me ? on the local and 'Shift_R /' on the remote machine.

    Nevertheless -xkb was the solution for my problem.

    So, thank you very much for publishing this artikle.

    ReplyDelete
  6. I had this "shift key not working at all" problem today, with tightvnc on win7's end, and x11vnc on ubuntu's end.
    Was working fine before, and 5 minutes after that I can no longer login to gnome. I go check, and I am not able anymore to do uppercase keys, none of the shift keys worked.
    Restarted telnet session, restarte x11vnc, even restarted ubuntu, nothing.
    So possibly it is something to do with the latest updated packages on lucid, even if this didn't happen right after I updated, so I am confused as to what may be the reason.

    ReplyDelete
  7. It's hard to tell what's wrong with your setup, without some debugging with xev, the -dk -dk command line options, etc.

    Have you tried another viewer at the win7 side?

    In any case, my own problem was that only *some* keys did not work right with the shift key pressed.

    Any chance you've started using a utility that captures the keyboard for its own use, before handing it over to other applications? it can be either on the ubuntu or on the win7 side...

    Good luck.

    ReplyDelete
  8. That did it: -xkb . Solves the ubuntu->ubuntu vnc using "vnc4viewer" client against "x11vnc" server. Shift works now.

    ReplyDelete
  9. Thanks for posting this - I was pulling my hair out over this issue!

    Matt

    ReplyDelete
  10. This was a great help! Using the -xkb switch solved this problem for me as well. Thank you for sharing the fruit of your labors.

    ReplyDelete
  11. Thank you, -xkb saved me as well!

    ReplyDelete
  12. Saved my whole office. Saved me hours of work. Thanks for sharing!

    ReplyDelete
  13. Thank you so much, -xkb fixed mine also.

    ReplyDelete
  14. I must say thank you for this ;)

    ReplyDelete
  15. -xkb works fine for me too, thanks!

    ReplyDelete
  16. I can't wait to try -xkb!

    ReplyDelete
  17. Thanks! I'll try when I reach home ^^

    ReplyDelete
  18. Thanks for posting this ! I also had the problem that the shift key wasn't working, you saved me a lot of time !

    ReplyDelete
  19. THanks, the -xkb worked like a charm!

    ReplyDelete
  20. I went into System > Preferences > Keyboard > Layout and in there swapped from a Dell to Dell 101 keyboard. That fixed it but maybe only temporarily until I have to flip it back.
    This has been a 'fix' me in VMware Workstation on Ubuntu too. VMware Workstation 7.1.2 seems to have the other fix (xkeymap) in the config file now, so it doesn't need to be added manually.

    ReplyDelete
  21. I had a similar problem, but -xkb didn't fix it.
    I tried DVP's solution and changed the keyboard layout (inside the VNC session) to a 102-keys (instead of 105-keys), and now SHIFT works!
    Thanks!

    ReplyDelete
  22. Thanks. This was the only site I could find that mentioned the -xkb fix, and it worked for me.

    ReplyDelete
  23. Thanks for the tip. Works on lucid vnc to lucid.

    ReplyDelete
  24. Thanks a lot for your effort of solving this. It saved my day!

    Cheers,
    Scott

    ReplyDelete
  25. Helped me with Lucid, too. Thanks for that.

    ReplyDelete
  26. Thank you soooo much for the solution to my problem. I've had this forever!

    ReplyDelete
  27. Thank you for posting this. I have had a "shift" problem with x11vnc for awhile, but today I decided to deal with it. I found your post immediately and the -xkb flag solved the problem right away!

    ReplyDelete
  28. Very useful! The -xkb worked like a charm!

    ReplyDelete
  29. Count me in with the numerous others. This solved my problem also. I had been using RealVNC's x0vncserver on a Linux machine running GNOME. My Win7 RealVNC viewer worked for the most part (I always had problems with "<", it always showed up as ">"), but when I tried using Mocha VNC Lite on my iPhone, that's when the problems really began. The shift key was completely ignored. After some troubleshooting I narrowed it down to the server and then found your article. Thanks so much for saving me hours of time. I switched over to x11vnc with your -xkb fix and it works like a champ!

    ReplyDelete
  30. This post is why the internet was invented. Exact problem I'm seeing, and -xkb fixed it. Thought I could be tricky to avoid typing "Adobe" by typing "?dobe" or "*dobe"... and realized that all of the useful wildcards require the shift key!

    Thanks for taking the time to document and post this. You rock.

    ReplyDelete
  31. I had almost gotten to the point where I was going to reinstall my remote VM when I stumbled upon your post because I added "shift" to my search engine query.

    Strangely enough I could only type standard lowercase letters while holding the shift key down and nothing else worked at all (no numbers or special characters and no upper case). Anyway I applied the fix and am update and upgrading my remote vm as I type this.

    Very grateful for the share. I ran into my really nasty issue accessing an Ubuntu 12.04LTS-beta2 running on a remote Ubuntu 10.04.3LTS from my OS X system. Everything was working great accessing an Ubuntu 12.04 VM running x11vnc from the same OS X system just before hand.

    LOL, not sure where the fault lay but if you are doing OSX -> Chicken of the VNC -> Ubuntu 10.04 running the latest Virtual Box where you are installing a VM running Ubuntu 12.04LTS-beta2 and all hell breaks loose with the keyboard in your VNC session to your remote virtual machine, well the above works just great for that too and is very much appreciated to say the least.

    Thanks!

    I have been reading a up a lot on x11vnc and had missed that particular option.

    ReplyDelete
  32. Saved the day again - many thanks for this post and -xkb

    ReplyDelete
  33. Thanks so much for posting this! I had the same problem, and -xkb was the fix for me, too.

    ReplyDelete
  34. Hello guys, after reading this post I will try to fix my problem with adding the -xkb option.

    However, could you tell me where exactly do I need to add it? I am not pretty much familiar with servers, I am using Red Hat 5.5 with vncserver installed.

    Thank you very much

    ReplyDelete