Because I don't give up as easily as I say I do, I spent another day with
the issue and was able to find an automatic workaround. Basically GNOME
44+ doesn't like it if the current X RandR mode is not the first in the
list, so the TurboVNC Server now ensures that it is. Changing the
resolution using 'xrandr -s {mode}' still behaves erratically with recent
GNOME releases (and only with recent GNOME releases), in that sometimes
'xrandr -s {mode}' doesn't change the resolution, and other times it
disables the X RandR output, which causes the desktop to disappear. That
can also be worked around by changing the resolution using 'xrandr --output
VNC-0 --mode {mode}'. In my testing with GNOME Ubuntu 24.04 and Fedora,
TurboVNC now behaves as expected, except for the aforementioned issues with
'xrandr -s'. I also verified that there are no behavior regressions when
using GNOME on Ubuntu 22.04 and Rocky Linux 8, and when using MATE on
Ubuntu 24.04.
On Monday, January 6, 2025 at 11:48:16 AM UTC-5 DRC wrote:
> I did finally find some issues that suggest general X RandR problems with
> GNOME 44+/X11:
>
>
> https://www.reddit.com/r/gnome/comments/1cimcu0/no_background_after_xrandr_in_gnome_46/
>
> https://www.reddit.com/r/Fedora/comments/14f9u5c/gnome_44_and_xrandr/
>
> The writing is on the wall that GNOME may not support X11 for much
> longer. You can read about the general problems with creating a Wayland
> VNC server here (and by following the links in the thread):
>
> https://github.com/TurboVNC/turbovnc/issues/18
>
> Essentially the problem is that, in Wayland, the compositor and window
> manager are integrated, so each window manager implementation (GNOME, KDE,
> etc.) has its own specific implementation of Wayland. There doesn't seem
> to be any kind of convergence around a common set of Wayland extensions for
> remote display, so it wouldn't be possible (at least at the moment) to
> develop a TurboVNC-like solution for Wayland. The more I dug into that
> problem, the more I also realized that the RFB protocol is very much a
> product of the limitations of X11 and 1980s displays. To really leverage
> the capabilities of Wayland, it would be much better to develop a new
> remote display solution from the ground up, a solution that is essentially
> a standalone Wayland compositor with remote window management built in.
> (Thus, you wouldn't run GNOME or KDE or whatnot in the compositor. The
> compositor would simply transmit the contents of application windows on the
> server to local windows on the client and take advantage of the client's
> window manager.) However, such a solution would be a herculean task--
> probably requiring an industry consortium to come up with an open protocol
> and multiple developers working full-time for at least a year to come up
> with a prototype. I don't see that happening in the open source
> community. The more likely scenario is that a company comes up with a
> proprietary solution for it, doesn't share their research, and makes open
> source remote display solutions increasingly irrelevant. As long as window
> managers like Xfce exist that will run on X11, then people will still be
> able to use TurboVNC, but applications and frameworks (GTK, Qt, etc.) will
> probably start defocusing from X11, if they haven't already. I am
> certainly very open to conversations regarding how to mitigate that
> situation, which may mean collaborating with other players in the open
> source remote display field.
>
> On Sunday, January 5, 2025 at 2:52:59 PM UTC-5 DRC wrote:
>
>> Never mind. The workaround was a red herring. I discovered that I could
>> work around the immediate problem, whereby GNOME crashes if one of the
>> default X RandR resolutions is initially specified in the TurboVNC session
>> (by using -geometry/$geometry), but then if I change the resolution with
>> 'xrandr -s', the crash still occurs. Both the O/S-provided TigerVNC 1.13.1
>> package and the project-provided TigerVNC 1.14.1 package demonstrate some
>> variation of the same issue. The O/S-provided package behaves similarly to
>> TurboVNC. The project-provided package behaves similarly to the workaround
>> I tried, in that it allows a default X RandR resolution to be initially
>> selected with -geometry/$geometry but subsequently fails if a default X
>> RandR resolution is selected with 'xrandr -s'. (If a default X RandR
>> resolution was initially selected, then attempting to select another
>> default resolution with 'xrandr -s' causes the resolution to briefly change
>> but immediately revert to the previous resolution. If a non-default X
>> RandR resolution was initially selected, then attempting to select a
>> default resolution with 'xrandr -s' causes GNOME to stop displaying the
>> desktop or responding to input, so it has effectively crashed.)
>>
>> Note that I can also reproduce the failure with recent versions of GNOME
>> on Fedora. Based on the fact that GNOME 44 in Fedora 38 fails but GNOME 42
>> in Ubuntu 22.04 doesn't, the issue must have been introduced in GNOME 43 or
>> 44.
>>
>> I could unfortunately write a book about how GNOME has become
>> increasingly hostile to remote display environments. I could write another
>> book about how Wayland has complicated the remote display picture to the
>> point that Linux remote display developers basically can't figure out where
>> to go from here. For me personally, I'm trying to maintain TurboVNC as
>> best I can, but with no R&D budget or staff or salary, I have no ability to
>> be proactive or forward-looking. That's why, when I observe issues like
>> this with a recent platform, I look at TigerVNC to see if they have fixed
>> or worked around it. (Development of TigerVNC is primarily funded through
>> sales of a commercial/semi-proprietary product built around it, so they
>> have a lot more flexibility than I do.) If they have fixed or worked
>> around it, then I can adopt their fix. Otherwise, however, I unfortunately
>> can't devote the weeks of labor that would likely be required to track this
>> down, since no one is paying for that labor. My standard rant on this is
>> that Linux graphics stack developers are acting as if remote display has no
>> relevance, when I would argue that the potential relevance of Linux as a
>> remote display platform is much higher than the potential relevance of
>> Linux as a desktop platform.
>>
>> tl;dr: Use the workaround I mentioned earlier, i.e. changing the
>> resolution remotely, or use another window manager.
>>
>> On 1/4/25 2:49 PM, DRC wrote:
>>
>> It does in fact appear that I can work around this by changing our X
>> RandR logic. Stand by. I will look into it more early next week.
>> On 1/3/25 6:13 PM, DRC wrote:
>>
>> Unfortunately I am clueless at this point. Given that the issue also
>> occurs with TigerVNC and doesn't occur with any other WM or any other O/S
>> distribution, there isn't much I can do to isolate it. I googled around
>> and didn't find any other reports of it. There unfortunately isn't
>> anything else I can do barring further information.
>> On 1/3/25 1:46 PM, DRC wrote:
>>
>> Disregard my previous remark about a black screen. That was user error.
>> I can now reproduce exactly the issue you report. In fact, specifying any
>> resolution that is in the default list of resolutions reported by X RandR
>> causes the failure. If I remove 1440x900 and 1920x1080 from that list,
>> then those resolutions can then be selected with -geometry/$geometry. Same
>> goes for the TigerVNC Server. I am still investigating.
>>
>> On 1/3/25 12:36 PM, DRC wrote:
>>
>> Reproduced. In my case, specifying -geometry (or $geometry in
>> turbovncserver.conf) never works. It fails with the "Oh No! Something has
>> gone wrong!" screen if I specify 1440x900, but it fails with a black screen
>> otherwise. The same happens with TigerVNC, and TigerVNC's startup
>> mechanism is so different from TurboVNC's that that strongly suggests a
>> GNOME bug. Other window managers, such as MATE or Xfce, work fine. As a
>> workaround, you can start the TurboVNC Server with no arguments and then
>> pass '-desktopsize 1440x900' to the TurboVNC Viewer when connecting (or
>> enter 1440x900 into the "Remote desktop size" field of the Connection tab
>> in the TurboVNC Viewer Options dialog.)
>>
>> I am investigating whether a more automatic workaround might be possible.
>>
>>
>> On 12/23/24 10:31 AM, Andrea Farina wrote:
>>
>> Dear DRC,
>> My client is on a MacBookPro M1. I’ve installed TurboVNC viewer, RealVNC
>> and the embedded screen Sharing.
>> All of them present the same error when I try to connect using the
>> -geometry 1440x900 option. I tried another things: using the -geometry with
>> many resolutions; here is the report:
>> 1200x900 working!
>> 1300x900 working!
>> 1400x900 working!
>> 1440x900 not working (waht I’ve always used before)
>> 1920x1080 not working
>> 1200x1080 working!
>> 1728x1117 working! (my halved 16inches resolution monitor)
>>
>> So I honestly think that the problem is in some strange combination of
>> resolutions. Hope this can help!
>> Best regards!
>> Andrea
>>
>>
>>
>> On 23 Dec 2024, at 15:55, 'DRC' via TurboVNC User Discussion/Support
>> <turbovn...@googlegroups.com> wrote:
>>
>> The TurboVNC Server isn’t invoking xinitrc, so my previous suspicion was
>> incorrect. At this point, I will have to try reproducing the issue. What
>> VNC viewer are you using, and what client O/S? I ask because the session
>> log indicates that the TurboVNC Server is enabling the outdated and slow
>> ZRLE encoding, which would never happen if you were connecting with the
>> TurboVNC Viewer.
>>
>> On Dec 23, 2024, at 2:39 AM, Andrea Farina <andreaf...@gmail.com> wrote:
>>
>> Dear DRC,
>> Here attached the two log files obtained with and without -geometry
>> option. They look pretty the same except a part with warnings related
>> to XKEYBOARD keymap compiler (xkbcomp) that is present two times in the
>> working log and one time in the not_working log.
>> Hope this can help finding the issue, which is probably related only to
>> my installation…
>> Best regards
>> Andrea
>>
>>
>>
>> On 22 Dec 2024, at 21:28, 'DRC' via TurboVNC User Discussion/Support
>> <turbovn...@googlegroups.com> wrote:
>>
>> Can you check the TurboVNC session log under ~/.vnc on the server. It
>> occurs to me that the TurboVNC Server may be trying to execute xinitrc
>> because the GNOME session desktop file isn’t available (due to a missing
>> package.)
>>
>> On Dec 22, 2024, at 12:01 PM, Andrea Farina <andreaf...@gmail.com> wrote:
>>
>> Dear DRC,
>> here are the exact steps.
>> In September I’ve upgraded from 20 to 22. I had TurboVNC 2.x and after
>> the upgrade I’ve also update to the last version that was 3.03. No problem
>> and all started to work smoothly.
>>
>> On Friday I had to further upgrade because I’ve received a vulnerability
>> report from my ICT admin because of the OpenSSH version 8.9. So I had to
>> update to 9.3 that is supported by UBUNTU 24. After the upgrade I had the
>> TurboVNC version 3.03 already installed and I’ve received the same error,
>> this is because I update to 3.1. So, at my knowledge, at least TurboVNC
>> 3.03 has the issue.
>> Actually, I cannot try the older versions because the machine is shared.
>> What I guess is that it might be a problem due to the fact that I don’t
>> have a fresh installation but a 2 times updated version of Ubuntu…
>> Thanks a lot
>> Andrea Farina
>>
>> [image: image.png]
>>
>>
>> Il giorno 22 dic 2024, alle ore 17:35, 'DRC' via TurboVNC User
>> Discussion/Support <turbovn...@googlegroups.com> ha scritto:
>>
>>
>> I mentioned TVNC_USERDBUS in case you were using GNOME Classic, but that
>> environment variable should not be necessary with plain (non-classic)
>> GNOME. I will try to reproduce the issue, but I may not be able to. (This
>> sort of issue tends to be system-specific and may not even be related to
>> TurboVNC.) The best thing you can do to debug it is to try prior versions
>> of TurboVNC. Try 3.1, then try 3.0.3, then 3.0, then 2.2.7. Stop as soon as
>> you find a version that behaves either better or worse than the current
>> version— that is, a version that either doesn’t exhibit the bug or exhibits
>> a worse bug. (The version of GNOME in Ubuntu 24.04 may not work with
>> TurboVNC 2.2.x, for instance.) What I’m looking for is some way to narrow
>> down a specific version of TurboVNC that might have introduced the issue,
>> which may give me a clue as to the feature that introduced it, which may
>> give me a clue as to how to reproduce and fix it.
>>
>> On Dec 22, 2024, at 3:27 AM, Andrea Farina <andreaf...@gmail.com> wrote:
>>
>> Dear DRC, sorry I'm not so expert in those things!
>> On the physical machine each user has the standard desktop is GNOME. If I
>> successfully connect without the -geometry options, the result of the
>> command
>> wmctrl - m is GNOME Shell, so I guess GNOME is what I try to use with
>> TurboVNC.
>> I use the standard xstartup.turbovnc file in the folder /opt/TurboVNC/bin
>> that is the same you can download from Github
>> https://github.com/TurboVNC/turbovnc/blob/main/unix/xstartup.turbovnc.
>> I've tried to put in the second line TVNC_USERDBUS=1 and connect with
>> -geometry but without success.
>>
>> If you can explain me more in details which commands I have to use I can
>> debug the problem.
>>
>> Thanks a lot!
>>
>> Andrea
>>
>>
>> On Sunday, 22 December 2024 at 01:23:16 UTC+1 DRC wrote:
>>
>>> That shouldn’t happen. Please answer my question regarding which window
>>> manager you are using.
>>>
>>> On Dec 21, 2024, at 5:59 PM, Andrea Farina <andreaf...@gmail.com> wrote:
>>>
>>> Dear DRC,
>>>
>>> thank you very much. I've tried to set the variable using the command
>>> *export TVNC_USERDBUS=1* before creating the display with
>>> */opt/TurboVNC/bin/vncserver :2 -geometry 1440x900*
>>> but the problem still remains.
>>> I could solve it discarding the option -geometry 1440x900. Don't know
>>> why, but in the last versions I could set geometry without problems.
>>> Thanks again
>>> Regards
>>> Andrea
>>>
>>>
>>> On Friday, 20 December 2024 at 22:28:00 UTC+1 DRC wrote:
>>>
>>>> Which window manager are you attempting to use? I have tested GNOME,
>>>> MATE, and Xfce under Ubuntu 24.04 with no issues. There is a known
>>>> issue with the GNOME Classic window manager on Ubuntu 24.04, however.
>>>> In order to use GNOME Classic/Ubuntu 24.04 with TurboVNC, you have to
>>>> set TVNC_USERDBUS=1 in the environment, which limits you to one
>>>> simultaneous session.
>>>>
>>>> DRC
>>>>
>>>> On 12/20/24 1:39 PM, Andrea Farina wrote:
>>>> > Dear users,
>>>> > I'm been using TurboVNC installed on LINUX since 2020 without
>>>> > problems. Now I've upgraded to UBUNU 24 and I've installed the last
>>>> > version 3.1.3.
>>>> > Wgen i start the server on the limux machine all goes smoothly but,
>>>> > when I try to connect from my MacBook both using VNCConnect and the
>>>> > embedded Screen sharing, after inserting the password I get the
>>>> error:
>>>> > "Oh No! Something has gone wrong!" and no way to connect.
>>>> >
>>>> > If, instead of TurboVNC I use RealVNC or the standard vncserver the
>>>> > connection is accepted but with a very poor graphics. I would like to
>>>> > continue using TurboVNC because, I can manage multiple vnc displays
>>>> > for many users with an init script.
>>>> >
>>>> > Do you know how to manage this problem? Are there some security
>>>> limits
>>>> > on the connection?
>>>> > Thanks a lot!
>>>> > Andrea
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "TurboVNC User Discussion/Support" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to turbovnc-user...@googlegroups.com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/turbovnc-users/c38c9db9-c7d7-44e4-a9c2-0fd418275033n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/turbovnc-users/c38c9db9-c7d7-44e4-a9c2-0fd418275033n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/fbb360c7-7778-4844-84cf-d9790b47c926n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/fbb360c7-7778-4844-84cf-d9790b47c926n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/125177A4-46A9-4C50-9F35-5FCD5A1A75A1%40virtualgl.org
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/125177A4-46A9-4C50-9F35-5FCD5A1A75A1%40virtualgl.org?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/FDC0649F-3191-4E32-883B-8EF9D14A1E96%40gmail.com
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/FDC0649F-3191-4E32-883B-8EF9D14A1E96%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/DBDA2518-C456-4C6C-8B42-E02E4190D3A1%40virtualgl.org
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/DBDA2518-C456-4C6C-8B42-E02E4190D3A1%40virtualgl.org?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>> <log_without_geometry_working.log>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>> <log_with_geometry_not_working.log>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/C7663621-67D6-4D52-AEDD-8C94812E7C30%40virtualgl.org
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/C7663621-67D6-4D52-AEDD-8C94812E7C30%40virtualgl.org?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TurboVNC User Discussion/Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to turbovnc-user...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/turbovnc-users/208507FE-4B86-4B4E-8665-85A6C09FAF73%40gmail.com
>>
>> <https://groups.google.com/d/msgid/turbovnc-users/208507FE-4B86-4B4E-8665-85A6C09FAF73%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
You received this message because you are subscribed to the Google Groups
"TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/turbovnc-users/26213571-4531-47b5-a577-383648d9015en%40googlegroups.com.
