Smart resize on VNC session doesn't work on some Windows machines

Smart resize on VNC session doesn't work on some Windows machines

avatar

Hi,

This is a weird one. I am connecting from Windows 11 to a RHEL 8.8 tigerVNC server. For one user, the smart resize works. The resolution scales with the window size. On the other one, it doesn't work. The resolution is fixed...Both are running 2025.2.30.0 (although the one working is JIT, the one failing is PreJIT) and using the same connection settings....

Any idea where to start debug the session?

Thank you very much

All Comments (11)

avatar

Hello

One thing that stands out from your post is the JIT versus PreJIT; and although I cannot envision a scenario where the PreJIT would cause this to not work - I think we should rule it out in the first case. Software can be weird sometimes.

The simplest would be, to ask the user to download a portable JIT build from the website and quickly try the connection using that (so they don't need to do the uninstall / reinstall dance). That's the "zip universal" download on the website.

Please let me know if something isn't clear

Kind regards,

Richard Markievicz

avatar
Hello

One thing that stands out from your post is the JIT versus PreJIT; and although I cannot envision a scenario where the PreJIT would cause this to not work - I think we should rule it out in the first case. Software can be weird sometimes.

The simplest would be, to ask the user to download a portable JIT build from the website and quickly try the connection using that (so they don't need to do the uninstall / reinstall dance). That's the "zip universal" download on the website.

Please let me know if something isn't clear

Kind regards,


@Richard Markiewicz
Thank you. I will try and report back.

Just a note that the JIT version is from software update and PreJIT version is from the website. It's the ".msi, x64".

avatar
Hello

One thing that stands out from your post is the JIT versus PreJIT; and although I cannot envision a scenario where the PreJIT would cause this to not work - I think we should rule it out in the first case. Software can be weird sometimes.

The simplest would be, to ask the user to download a portable JIT build from the website and quickly try the connection using that (so they don't need to do the uninstall / reinstall dance). That's the "zip universal" download on the website.

Please let me know if something isn't clear

Kind regards,


@Richard Markiewicz
Thank you. I will try and report back.

Just a note that the JIT version is from software update and PreJIT version is from the website. It's the ".msi, x64".


Hi @Richard Markiewicz ,

The JIT version works. We ended up installing the universal installation versions as well. Thank you.

avatar

Hello

That's really unexpected; and I did just try this on a PreJIT build for ARM and found it to work well. So maybe there is a problem with x64.

This is a weird issue; if using the JIT build is an acceptable workaround for you I probably won't look into it further for now. The advantage of the PreJIT build is a faster startup time for RDM.

If you want to look into this further please let me know and I can provide some further troubleshooting steps.

Thanks and kind regards,

Richard Markievicz

avatar
Hello

That's really unexpected; and I did just try this on a PreJIT build for ARM and found it to work well. So maybe there is a problem with x64.

This is a weird issue; if using the JIT build is an acceptable workaround for you I probably won't look into it further for now. The advantage of the PreJIT build is a faster startup time for RDM.

If you want to look into this further please let me know and I can provide some further troubleshooting steps.

Thanks and kind regards,


@Richard Markiewicz
Hi, yes, using a JIT build is okay for us although we do notice it takes a while to load RDM. I am actually searching for options to speed it up! So I can help you to check what would be the problem. Thanks

avatar

Hi @Richard Markiewicz,

I just reinstalled the RDM PreJIT version on my own laptop but I cannot produce what I see previously. The scaling works. I think this has been fixed in the 2025.3.15.0?

Thanks

Song

avatar

Hi @Richard Markiewicz ,

I just noticed that the smart scaling stops working again even with the latest 2025.3.15.0 for that user. She hasn't done anything other than change a FortiClient IPSec VPN connection...I wonder if it is something with the OS that is causing it. Thank you

Best regards,

avatar

Hello

Ok, that sounds really strange. I doubt it's something at the OS-level. Display resize is negotiated as part of the VNC protocol "handshake"; we need to see if that is failing or doing something unexpected; or if it's negotiated properly but RDM is somehow not requesting or receiving the subsequent resolution changes.

On the affected user machine:

  • Go to File > Settings > Entry Types > Sessions > Apple Remote Desktop (ARD) / VNC > Advanced
  • Check the box for "Enable logging for ARD and VNC"
  • Provide a path to create a log file (e.g. C:\username\desktop\rdm-vnc.log)
  • Save the changes and restart RDM


Now, once the problem is reproduced, you can send me the log file from the path we specified before.

Please, let me know if something isn't clear or you have further questions

Kind regards,

Richard Markievicz

avatar

Hi @Richard Markiewicz ,

For one machine, it starts working again so I cannot get the log anymore.

But we have a new machine setup for a new Linux account. The same issue happens again with the latest version of RDM. The log is attached. If it helps, both machine are connected to a Dell 34inch wide monitor during first setup. The VNC session is the first time the user login on Linux GNOME.

Thank you for your help.

VNC_smart_resize_problem_20251027.log

avatar

Hello

Thanks for the log file. I can see that the desktop sizing is negotiated and RDM is requesting the server to set its desktop size, and the server is responding normally. So in that regard everything looks normal. I'll have to debug this and try to see if RDM or the server is doing something slightly unexpected or off-spec, which results in this not always working properly.

Just to confirm - the server is TigerVNC, right?

Kind regards,

Richard Markievicz

avatar

Hi Martin,

Right, it's TigerVNC on RHEL8.8 (we version locked it so it's not receiving any update beyond 8.8). Details below

tigervnc-server-minimal-1.12.0-15.el8_8.x86_64
tigervnc-server-1.12.0-15.el8_8.x86_64


Note that the same account works on my laptop. And my account doesn't works on the laptop with issue either....so it feels like it's the client causing issues

Best regards,