Bug#836324: tightvncserver: Typing gives wrong keys in some apps

[Matthew Gabeler-Lee]

Package: tightvncserver
Version: 1.3.9-8
Severity: important

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.

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tightvncserver depends on:
ii libc6 2.23-5
ii libjpeg62-turbo 1:1.5.0-1
ii libx11-6 2:1.6.3-1
ii libxext6 2:1.3.3-1
ii perl 5.22.2-3
ii x11-common 1:7.7+16
ii x11-utils 7.7+3
ii xauth 1:1.0.9-1
ii xserver-common 2:1.18.4-1
ii zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages tightvncserver recommends:
ii x11-xserver-utils 7.7+7
ii xfonts-base 1:1.0.4+nmu1

Versions of packages tightvncserver suggests:
ii tightvnc-java 1.2.7-9

-- no debconf information

[Ola Lundqvist]

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

--
--- Inguza Technology AB --- MSc in Information Technology ----
/ o...@inguza.com Folkebogatan 26 \
| op...@debian.org 654 68 KARLSTAD |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------

[Matthew Gabeler-Lee]

On Sat, 3 Sep 2016, Ola Lundqvist wrote:

> Also interesting that the problem goes away with vnc4server.

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.

> What client software do you use?

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.

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9

[Ola Lundqvist]

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

[Sven Geuer]

Control: tags -1 = unreproducible,moreinfo

Hi Matthew,

On Thu, 01 Sep 2016 12:43:16 -0400 Matthew Gabeler-Lee
<che...@fastcat.org> wrote:
> Package: tightvncserver
> Version: 1.3.9-8
> Severity: important
>
> 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 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

--
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585

[Matthew Gabeler-Lee]

On Sat, 7 Aug 2021, Sven Geuer wrote:

> 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?

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

--
-- Matt

[Sven Geuer]

Control: retitle -1 tightvncserver: XKeyboard extension not available
Control: tags -1 = wontfix

Hi Matthew,

On Fri, 2021-08-13 at 23:15 -0400, Matthew Gabeler-Lee wrote:
> [...]

> 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
>

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!