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.