Our last vendordrop of TigerVNC was 2020-06-01. We need to get back in sync.
It looks like commit 10d9a8d9122effd16bdad230dbf634c5e714ca6b is where we last did a vendor drop.
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
We'll also be reverting bug 5474 as we decided on bug 5475 that this wasn't a method we wanted to continue using.
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)
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.
(In reply to Pierre Ossman from comment #6) > * Exit error dialog hack (maybe handled on bug 286) That should have been bug 289.
Confirmed that we don't load or store any configuration (via strace). However I did discover bug 7799, but it's not a regression.
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.
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.
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
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.
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.
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.
Did some more debugging and the latency issue is a bug, but not a regression. Added bug 7800 to track it.
That should be everything. Not adding release notes here since all significant changes have their own separate bugs.
(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
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
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.
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
The changes related to relative pointer input in this vendor drop of TigerVNC were tested in bug 7794, comment 14.
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.
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.
(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.
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.
It seems the cursor handling is buggy and can cause the client to disconnect: https://github.com/TigerVNC/tigervnc/issues/1409 Fortunately it doesn't affect us as we prefer another cursor encoding. We'll get the fix in the next vendor drop though.
We did another vendor drop for bug 7822, which includes the fix for the issue mentioned in comment 32.
