tightvncserver was working fine for me for a long time until I restarted my
VNC server session recently.  Now I find that in most apps I can type fine,
but certain apps get the keys all wrong.  Nearly the entire un-shifted US
keyboard (letters and numbers) are coming out wrong.

I discovered this in bitcoin-qt, but xkeycaps also shows the problem
behavior.

Unaffected include firefox, lxterm, and even xev.

Interestingly, in xkeycaps, the keycode shows correct (e.g.  the 1 key shows
1) but the keysym shows wrong (e.g.  the 1 key shows 9).

Switching to vnc4server instead of tightvncserver makes this problem go
away.

Note: this is not the same behavior has these other old bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545939
I have the workaround for this one in place.  Turning it on or off does not
affect the problem I'm describing here.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514476
Using a US keyboard, and in my case pretty much ALL keys are broken, not
just some, and nothing is accidentally shifted or such.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698859
Again, different set of keys broken for me, not just a couple but nearly
all.

Hi Matthew

Interesting. I'm quite sure there are several key mapping functions
and different applications use different ones. They all have to be in
sync to make it work.

But I have not seen any report with the un-shifted keyboard parts.
That is really strange.

Also interesting that the problem goes away with vnc4server.

What client software do you use?

// Ola

Hi Matthew

Interesting. I'm quite sure there are several key mapping functions
and different applications use different ones. They all have to be in
sync to make it work.

But I have not seen any report with the un-shifted keyboard parts.
That is really strange.

Also interesting that the problem goes away with vnc4server.

What client software do you use?

// Ola

I just came across tigervnc which has the tight protocol support and
does not suffer from this bug.

The tigervnc website says it's based on the newer vnc4 branch of
tightvnc that never got released, so this may be a bugfix in vnc4 that
was not in the older tightvnc 1.3 code.

I tried many, including vinagre, remmina, and the uber-basic vncviewer,
all had exactly the same problem.

####

FWIW, since tigervnc does everything (for me) that tightvnc did, and
doesn't have this bug, switching to that package functions as a "fix"
for this for me, and I'm no longer concerned about tightvnc, esp. since
it seems to be effectively unmaintained upstream, at least for open
source linux packaging.

Hi Matthew

Thank you for the information. It looks like it was a good decision to go
for tigervnc. Tigervnc have just recently been included in unstable and
testing and will be part of the next stable release.

I have the intention to remove both tightvnc and vnc4 due to the lack of
upstream development and go only for tigervnc. However I would like to know
more about reactions on tigervnc (bugs) before they are finally requested
for removal.

Best regards

// Ola

On 8 November 2016 at 17:24, Matthew Gabeler-Lee <cheetah@fastcat.org> wrote:

Hi Matthew,
[...]

I tried to reproduce your observation using tightvncserver 1:1.3.10-3
but didn't encounter any key mapping issues.

Can you provide me with instuctions how to verify this bugs still
persists?

Sven

I've been continuing with TigerVNC for the nearly 5 years since this
bug, so it's quite possible ... something ... changed and it's not
broken any more :)

FWIW, my setup hasn't really changed much, however. The vnc server runs
my ~/.xsession which:
1. xscreensver &
2. xset s off
3. osdsh
4. echo "Xft.dpi: $(xdpyinfo | sed -nre '/^[[:space:]]*resolution:[[:space:]]*([0-9]+)x([0-9]+) dots per inch.*/{s/^.*x([0-9]+) dots .*/\1/;p}')" | xrdb -
   (I've no idea why this is in there ... parts of this .xsession script
   are literally 20 years old. I think this is maybe a workaround for
   some issues with weird font sizes under VNC)
5. exec wmaker

Hi Matthew,

Thanks for providing your .xsession file. I was able to reproduce your
observations in some way, even without any explicit .xsession file.

With xkeycaps, for example pressing the '1' key a KeySym of '1' is
reported while the KeyCode is '9'. That's the other way around than you
described it originally, what may have happened erroneously.

bitcoin-qt doesn't even start up, it aborts complaining

	qt.qpa.xcb: XKeyboard extension not present on the X server

And indeed, the X server incorporated in tightvncserver does not
provide the XKeyboard extension, xdpyinfo does not list it. It is
available from the source, but the build instructions explicitly
disable it for whatever reason. 

This is an upstream related issue therefore, but upstream does not
maintain Thightvnc on Linux any more. Thus, do not expect the XKeyboard
extension to be implemented in tightvncserver going forward.

Sorry for the bad news!

Sven