Bug 7785 - We're out of sync with upstream TigerVNC
Summary: We're out of sync with upstream TigerVNC
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Pierre Ossman
Keywords: frifl_tester, linma_tester, prosaic
Depends on: 7778
Blocks: 7782 7794 4734 5250 7006 7007 7201 7267 7795
  Show dependency treegraph
Reported: 2021-10-29 16:13 CEST by Samuel Mannehed
Modified: 2022-01-24 09:21 CET (History)
3 users (show)

See Also:
Acceptance Criteria:


Description Samuel Mannehed cendio 2021-10-29 16:13:16 CEST
Our last vendordrop of TigerVNC was 2020-06-01. We need to get back in sync.
Comment 1 Pierre Ossman cendio 2021-11-17 09:19:31 CET
It looks like commit 10d9a8d9122effd16bdad230dbf634c5e714ca6b is where we last did a vendor drop.
Comment 2 Pierre Ossman cendio 2021-11-17 13:22:47 CET
Major things are split off to their own bugs, but some minor things we need to look at on this bug:

* The core RFB code now depends on pixman, so we need to make sure we always have that
* The client's bandwidth got a rewrite
* The comparing update tracker got tweaked
* There has been work done on Japanese and Korean keyboard support
* Applications are now notified that the clipboard is gone if a client disconnects while owning it
* The default session name is changed, perhaps we don't have to handle that manually anymore?
* The client has gotten a reconnect feature we need to disable
* We can remove the workaround for a new cmake
Comment 3 Pierre Ossman cendio 2021-11-17 13:36:31 CET
We'll also be reverting bug 5474 as we decided on bug 5475 that this wasn't a method we wanted to continue using.
Comment 6 Pierre Ossman cendio 2021-11-18 14:38:00 CET
Merge conflicts that need testing:

 * Shadowing
 * Options dialog (will be handled under bug 7006)
 * Disabled loading and storing of configuration
 * Exit error dialog hack (maybe handled on bug 286)
 * Translations (maybe handled on bug 7270)
Comment 8 Pierre Ossman cendio 2021-11-18 16:30:00 CET
Shadowing is unfortunately broken now. Most of it works, but not the notification that a user is no longer shadowed. I think the new connection states are causing issues.
Comment 11 Pierre Ossman cendio 2021-11-19 10:36:40 CET
(In reply to Pierre Ossman from comment #6)
>  * Exit error dialog hack (maybe handled on bug 286)

That should have been bug 289.
Comment 12 Pierre Ossman cendio 2021-11-19 13:50:04 CET
Confirmed that we don't load or store any configuration (via strace). However I did discover bug 7799, but it's not a regression.
Comment 14 Samuel Mannehed cendio 2021-11-24 16:26:48 CET
I could see the reconnect dialog using a nightly build 2275. I used iptables to stop any traffic on the port used by ThinLinc's vncviewer:

> sudo iptables -I INPUT -p tcp --dport 33775 -i lo -j REJECT

The port (33775 above) was found using `ps aux | grep vncviewer`. Instantly I was no longer able to interact with the session. After a couple of minutes vncviewer gave up and showed the reconnect dialog.

Using build 2276 I was no longer able to see the reconnect dialog.
Comment 15 Linn cendio 2021-11-26 12:55:29 CET
Tested Korean keyboard changes shallowly on server build 2355 on RHEL 8 and client build 2279 on Fedora 33. 

The fix is regarding the Hangul key and the Hanja key, and the only way I could trigger these keys was by using 'xdotool':
> # Hangul key
> xdotool key 0xff34
> # Hanja key
> xdotool key 0xff31
I used 'xdotool' on the client side, and used 'sleep' before the call to be able to change my focused window to the ThinLinc client.
On the server side I used 'xev' to see the incoming key presses.

The Hangul key toggles between typing in korean characters and latin letter. When a korean character is highlighted and the Hanja key is pressed, a list of hanja suggestions is shown. When the Hanja key is pressed again, the list closes.

I did not find any good xdotool variant for Windows, so I was not able to test the Windows specific changes.
Comment 16 Linn cendio 2021-11-26 12:57:50 CET
Tested Japanese keyboard changes shallowly on server build 2355 on RHEL 8 and client build 2279 on Fedora 33. 

I used a japanese keyboard (layout OADG109A) for testing the Kana-key, for the other keys I used 'xdotool' on the client side like described in comment 15.

Key symbols [1] used:
Zenkaku_Hankaku  0xff2a
Eisu_toggle      0xff30
Romaji           0xff24
Kanji            0xff21

Using 'xev' on the server side I could see that the correct key was sent. However, the only change I could notice in the session was when pressing the Kana key, and the input would toggle between defaulting to hiragana or katakana. 

I wasn't able to test the changes on Windows or on macOS.

[1]: https://gitlab.com/cunidev/gestures/-/wikis/xdotool-list-of-key-codes
Comment 17 Linn cendio 2021-11-26 13:45:53 CET
Testing of at least the client's bandwidth as well as the default session name also needs to be done before this bug is ready for verification.
Comment 19 Pierre Ossman cendio 2021-11-29 13:54:58 CET
We checked the client's bandwidth handling, and it seems to behave roughly the same as it did before, which isn't fantastic:

 * It tends to overestimate the bandwidth, so above 16 Mbps you constantly get high quality

 * At around 10 Mbps it fluctuates a lot depending on content, switching between the two JPEG quality levels

 * Detecting very low bandwidth doesn't seem to work reliably in new or old version. It's supposed to trigger at 256 kbps, but it happens very randomly.

So the verdict is that improvements are still needed, but it's no worse than before so it's a project for the future.
Comment 20 Pierre Ossman cendio 2021-11-29 13:55:49 CET
We saw some oddities with the latency handling when testing where the latency could grow to absurd levels when the bandwidth was low. Need to double check if this is a regression or not.
Comment 21 Pierre Ossman cendio 2021-11-29 17:24:40 CET
Did some more debugging and the latency issue is a bug, but not a regression. Added bug 7800 to track it.
Comment 22 Pierre Ossman cendio 2021-11-29 17:29:36 CET
That should be everything. Not adding release notes here since all significant changes have their own separate bugs.
Comment 23 Linn cendio 2021-12-06 15:49:01 CET
(In reply to Pierre Ossman from comment #2)
> Major things are split off to their own bugs, but some minor things we need
> to look at on this bug:
> ...
> * The comparing update tracker got tweaked

The comparing update tracker seem to have been updated in this commit [1]. This change won't be tested on its own, but will be tested through the general testing that will be performed on this bug.

[1]: https://github.com/TigerVNC/tigervnc/commit/ae38d967ea4aac937e6fce5c0aa00a4fc552b637
Comment 24 Frida Flodin cendio 2021-12-07 10:45:21 CET
Tested Japanese keyboard layout on macOS 12.0.1 after the changes in [1] and [2]. I did not test with a real keyboard but managed to send key codes to the system via this bash script:

> echo "set i to 0
> repeat while i < 15
> set i to i + 1
> delay 5
> tell application \"System Events\" to key code 102
> end repeat" | osascript

I changed the key code to 102 for Eisu-toggle and 104 for Hiragana-Katakana. When running 4.13.0 client I could see on the server that it did not work as expected by using 'xev'. When using nightly client 2287 I got the correct keys. Also made sure 'normal' keyboard input works fine.

[1] https://github.com/TigerVNC/tigervnc/commit/b2a09a2c314866a9c5ae30497d93316372bab13b
[2] https://github.com/TigerVNC/tigervnc/commit/0d22c7bd365637889c05dc3ad08652a3e719c46a
Comment 25 Frida Flodin cendio 2021-12-07 11:10:58 CET
I did not manage to test the Korean or Japanese layouts on Windows. But I tested some general keyboard input on Windows 10 and it works fine. Tested to write stuff and pressing some virtual keys like "Page up", "Escape", "Insert" and so on. Everything works as expected.
Comment 26 Frida Flodin cendio 2021-12-07 15:28:29 CET
I can verify that we now use the new default session name instead of setting it ourselves. The new default is the same as we had before so for the user there is no change. I looked at the code changes in [1] and the changes made in our code, and it all looks good. 

[1] https://github.com/TigerVNC/tigervnc/commit/775d432ec72055b3854d22a5fed7c43997e344da
Comment 27 William Sjöblom cendio 2021-12-08 09:53:48 CET
The changes related to relative pointer input in this vendor drop of TigerVNC were tested in bug 7794, comment 14.
Comment 28 Frida Flodin cendio 2021-12-08 10:18:47 CET
Verified that shadowing works as expected. Tested with server build 2371 on Ubuntu 20.04 and client build 2287 on RHEL 8. 

✓ Allowed shadower is allowed to shadow.
✓ Non-allowed shadower is rejected. 
✓ The pop up shadowing question is shown to the user.
✓ Answering 'yes' starts the shadowing session, and 'no' does not.
✓ When shadower disconnects there is a pop up notification to the user.
Comment 29 Frida Flodin cendio 2021-12-08 14:52:23 CET
I can verify that the reconnect feature is turned off in ThinLinc. I tested this via shadowing. If a shadower is rejected by the user (the user answers 'no' when asked if he/she accepts the shadowing) the shadower gets a notification that an unexpected error happened and "Connection refused by local user". Before we disabled the reconnect feature the shadower can choose to attempt to reconnect, but with nightly build 2287 there is no such option.
Comment 30 Linn cendio 2021-12-08 14:55:00 CET
(In reply to Pierre Ossman from comment #2)
> Major things are split off to their own bugs, but some minor things we need
> to look at on this bug:
> ...
> * Applications are now notified that the clipboard is gone if a client
> disconnects while owning it
Reproduced the issue with ThinLinc server 4.13.0 on RHEL 8:

1. Log in to the client
2. Copy something from the local machine, e.g. abc
3. In the ThinLinc session, use 'xsel -b' to show the content of the clipboard, should be abc.
4. Disconnect from the session
5. ssh to the server machine with 'ssh -X', run 'tl-env xsel -b', returns abc

Note that I also could see the content of the clipboard with 'xsel -p'.

Tested the fix with server build 2371 on RHEL 8 with client build 2287 on Fedora 33. In step 5, 'tl-env xsel -b' now returns nothing.
Comment 31 Linn cendio 2021-12-09 09:00:02 CET
Did some general testing with server build 2371 on RHEL 8 to make sure the vendordrop didn't break any fundamental parts. Tested with client build 2287 on Fedora 33. For more detailed test instructions, see the bug mentioned for each test group.

✓ Basic function tests (bug 7223)
  ✓ Graphics ok
  ✓ Keyboard working
  ✓ Mouse working

✓ Touch gestures (see bug 7518)
  ✓ Single finger tap
  ✓ Double finger tap
  ✓ Triple finger tap
  ✓ Long press
  ✓ Double finger drag
  ✓ Double finger pinch

✓ Clipboard synchronisation (bug 7228)
  ✓ Copying from local to remote
  ✓ Copying from remote to local

This was the last testing to be done for this bug, closing.
Comment 32 Pierre Ossman cendio 2022-01-18 10:29:23 CET
It seems the cursor handling is buggy and can cause the client to disconnect:


Fortunately it doesn't affect us as we prefer another cursor encoding.

We'll get the fix in the next vendor drop though.
Comment 33 William Sjöblom cendio 2022-01-24 09:21:39 CET
We did another vendor drop for bug 7822, which includes the fix for the issue mentioned in comment 32.

Note You need to log in before you can comment on or make changes to this bug.