Our last vendor drop was 2022-01-20, so a lot has happened since then. We should sync up.
The last upstream commit should be a1d755a5f833c47d9c6fde4da1ec7e9e8631f1ce.
We've done some clean-ups and improvements to the FLTK layout code in TigerVNC that we need to sync up with tlclient.
Upstream has fixed an unnecessary dependency on libX11 in Xvnc that will likely allow some cleanup of our linking.
Xvnc now (optionally) requires libxcvt. We might have already added that in the previous update of Xorg, though.
We will now get the code for DRI3 support (bug 3297). But there are more things needed than just the code, so it will likely not get enabled at this time.
The upgrade exposes an issue with our static linking. When we switched to cblink in bug 6341, some shortcuts were taken when it comes to libstdc++. This is an implicit library, and hence isn't visible on the link command line. Which breaks the fundamental principle behind cblink. In some cases we've added -nodefaultlibs and explicitly added libstdc++ back so cblink can do its magic. But in some cases we just hope that it shows up by luck. With the vendor drop of TigerVNC, that luck has changed and the ordering has changed enough to break things. So we should look at fixing this more properly. gcc provides the flag -static-libstdc++ to solve this more sanely. Unfortunately, libtool (as always) messes up this advanced flag: https://savannah.gnu.org/support/index.php?111184 It might be the reason we didn't solve this issue properly during the original switch to cblink.
Tested ThinLinc client after the vendor drop on Windows 10, macOS 15.2 (x86), & Fedora 41. Did some simple testing and did not see any issues: * Keyboard grab * Touch gestures (Windows & Fedora) * Clipboard sync * Basic mouse/keyboard interactions However, the client crashed just as a connection is made on our M1 mac, with the following in tlclient.log: > 2025-02-06T12:51:23: vncviewer[E]: Assertion failed: (nsw), function cocoa_get_level, file /local/home/adaha/devel/ctc/buildarea/BUILD/thinlinc-client/tigervnc/vncviewer/cocoa.mm, line 47. This is the function that crashes in cocoa.mm: > void cocoa_set_level(Fl_Window *win, int level) > { > NSWindow *nsw; > nsw = (NSWindow*)fl_xid(win); > assert(nsw); // <-- crash here > [nsw setLevel:level]; > }
Custom changes that we need to verify: * Shadowing: * Client caption * Querying user * Disconnect notification * Shadowers not thrown out when normal user connects * Hide fields in connection info dialog * Hide entries in context menu * Options dialog in sync with tlclient * Hide socket errors * Translations (all OS) * Correct grouping with tlclient (Windows, macOS, GNOME) * Pinning vncviewer starts tlclient (Windows)
Tested the following on macOS 15.2 (x86), Windows 10 & Fedora 40 (GNOME) using server build 3908 and client build 3798: ✅ Shadowing: ✅ Client caption ✅ Querying user ✅ Disconnect notification ✅ Shadowers not thrown out when normal user connects ✅ Hide fields in connection info dialog ✅ Hide entries in context menu ✅ Options dialog in sync with tlclient ✅ Hide socket errors * This was quite difficult to reproduce. I took some inspiration from bug 289 and think I managed to test it correctly on Windows 10. By killing ssh.exe through the task manager, I get the following in tlclient.log, but no broken pipe error dialog from the client: > 2025-02-07T12:41:50: The SSH process unexpectedly exited before VNC viewer process. > 2025-02-07T12:41:50: vncviewer[E]: > 2025-02-07T12:41:50: vncviewer[E]: Fri Feb 07 12:41:50 2025 > 2025-02-07T12:41:50: vncviewer[E]: CConn: read: En befintlig anslutning tvingades att stänga av > 2025-02-07T12:41:50: vncviewer[E]: fjärrvärddatorn. (10054) ✅ Translations (all OS) * Correct grouping with tlclient (Windows, macOS(❌), GNOME) ❌ GNOME and Windows worked as expected. Running several instances of tlclient grouped them together as a single application. On macOS, however, each tlclient instance showed up as a new application in the bottom application bar. This is not a regression, and could confirm thath the behaviour is the same as in 4.18.0. ✅ Pinning vncviewer starts tlclient (Windows)
(In reply to Adam Halim from comment #14) > However, the client crashed just as a connection is made on our M1 mac, with > the following in tlclient.log: The issue here was not specific to the M1 mac and was triggered by starting a session in fullscreen. This was fixed upstream [1]. [1] https://github.com/TigerVNC/tigervnc/commit/1280c7176cdd607b06beae0f16e79e1ceefe7410
Should be all done now. > MUST: > > * ThinLinc should include the latest version of TigerVNC's master branch Yup. We now have the latest and greatest. > * Critical regressions should be fixed We have not found anything in our testing. > SHOULD: > > * All relevant changes for users should have bugzilla entries that are linked to this one Yup. Everything interesting should have its own bug, linked to this one. > * Fixes should be upstreamed Yup. We've done new vendor drops to stay in sync with fixes. > * Dependencies should be updated to the latest versions Not done at the moment, but we've added a bug to track it.
Note that there were some tweaks to the margins and fonts used in the UI. It's very subtle, though, so not worth the effort of regenerating all screenshots just for that.
Tested client build 3811 on Fedora 40, macOS 15 & Windows 10. I had a look at all available UIs in the client (options, sub-menus etc) and compared them to 4.18.0. Changes are very subtle, and I agree that it's not worth updating our screenshots now. I've looked through the commits and verified that our own patches were not lost in the merge when doing the vendor drop. This was also party confirmed by the testing done in comment #17. > MUST: > * ThinLinc should include the latest version of TigerVNC's master branch We do, as of right now, indeed have the latest and greatest. > * Critical regressions should be fixed We haven't found anything. > SHOULD: > * All relevant changes for users should have bugzilla entries that are > linked to this one Relevant changes are linked to this bug as "Blocks". > * Fixes should be upstreamed Fixes have been upstreamed & re-synced. > * Dependencies should be updated to the latest versions This will be done in bug 8503.
I got an unexpected error dialog from the when rebooting the ThinLinc server: > An unexpected error occurred when communicating with the server: > > Error reading rect: End of stream Unsure if this is a regression or not. Need to have a look. This is what the log said: > 2025-03-05T13:03:36: ssh[E]: SYSTEM ERROR: 104 > 2025-03-05T13:03:36: ssh[E]: Read from remote host 10.48.2.29: Connection reset by peer > 2025-03-05T13:03:36: ssh[E]: client_loop: send disconnect: Broken pipe > 2025-03-05T13:03:36: Process 646901 exited with code 255 > 2025-03-05T13:03:36: vncviewer[E]: > 2025-03-05T13:03:36: vncviewer[E]: Wed Mar 5 13:03:36 2025 > 2025-03-05T13:03:36: vncviewer[E]: CConn: Error reading rect: End of stream
The relevant code changed in this release, but it looks like the issue should exist with the previous code as well. So I would guess this is a regression since bug 7785. I did a few more attempts to reproduce this, and was unable to do so. I don't think it's an issue we need to resolve now.
