Resizing unreliable with wayvnc server

[x220]

Starting version 1.16.1 server doesn't change resolution after resizing window on the client. Version1.16.0 worked as expected.

• Server: Arch Linux tigervnc 1.16.2-1
• Client: Windows 10 vncviewer64-1.16.2

[CendioOssman]

Please fill out the bug template completely, as it contains vital details. E.g., how are you starting the server?

If you downgrade TigerVNC, does the issue go away? It would be good to verify that it wasn't something else that got upgraded and caused the issue.

[derekschrock]

I've been having a hard time with the latest release with both macOS and Windows.

It seems like the client (tigervnc) is trying to resize the remote desktop based off the n-1 size. I can't confirm with Windows client until tomorrow but on macOS it sesms like the resize it hanndling before the window is fully resized.

Currently I'm testing with:
FreeBSD 14.4

tigervnc-macos-1162.txt

wayvnc: v0.10.0
neatvnc: v1.0.0
aml: v1.0.0
river 0.5.0-dev.68+da8cf20fcb2c993 -xwayland
cow 2936ba27704e289
macOS TigerVNC 1.16.2

• Init. client connect with window off X by Y.
• alt-click + to max window the client
• The client resizes the remote desktop to X by (Y + small amount) while the window animates the resize

An example of this can be see with verbose log:

...
Mon May 25 19:06:11 2026
 CConnection: Key released: 58 => 0x38 / XK_Mode_switch (0xff7e)
 DesktopWindow: Requesting framebuffer resize from 1174x662 to 1178x665
 DesktopWindow: 1 screen(s)
 DesktopWindow:              0 (0x00000000): 1178x665+0+0 (flags 0x00000000)
...

1174x662 is the init window then the maxing window resizes to 1178x665.

After this you can opt-click + to unmax window then manually step window resizes to see it's using the pervious window size

option click + to unmax window

...
Mon May 25 19:09:37 2026
 CConnection: Key pressed: 58 => 0x38 / XK_Mode_switch (0xff7e)
 DesktopWindow: Requesting framebuffer resize from 1178x665 to 1437x845
 DesktopWindow: 1 screen(s)
 DesktopWindow:              0 (0x00000000): 1437x845+0+0 (flags 0x00000000)
...

Resize the window to something small (not 1142x650)

...
Mon May 25 19:10:24 2026
 DesktopWindow: Requesting framebuffer resize from 1437x845 to 1142x650
 DesktopWindow: 1 screen(s)
 DesktopWindow:              0 (0x00000000): 1142x650+0+0 (flags 0x00000000)
 DesktopWindow: 

Mon May 25 19:10:25 2026
 CConnection: SetDesktopSize failed: 4
 Viewport:    Resizing framebuffer from 1437x845 to 1142x650
...

Resizing the window to something larger:

...
Mon May 25 19:12:04 2026
 DesktopWindow: Requesting framebuffer resize from 1142x650 to 786x371
 DesktopWindow: 1 screen(s)
 DesktopWindow:              0 (0x00000000): 786x371+0+0 (flags 0x00000000)
 DesktopWindow: 

Mon May 25 19:12:06 2026
 CConnection: SetDesktopSize failed: 4
 Viewport:    Resizing framebuffer from 1142x650 to 786x371
...

I've attaced the full logs in case there's something I'm missing.

If you need more info I can provide it. Sometime later tomorrow I can test more with the Windows client however I think it's doing something along the same lines as the above with the macOS client.

[derekschrock]

Reverting back to 1.15.0 on macOS resizes work as expected.

[derekschrock]

This might be a neatvnc issue however with 1.15.0 and 1.16.x full screen resizes result in a error from neatvnc:

...
ERROR: ../src/server.c: 1931: Unknown display id: 984943658
...

Where this is something passed by the client:

DesktopWindow: Requesting framebuffer resize from 994x717 to 1440x900
 DesktopWindow: 1 screen(s)                                      
 DesktopWindow:      984943658 (0x3ab50c2a): 1440x900+0+0 (flags 0x00000000)
 DesktopWindow: 
 Config:      Set FullScreen(Bool) to on

984943658 from the DesktopWindow line. Is this expected? Windowed resizes always have this value as 0.

[derekschrock]

What am I thinking.. I can test this at home as well with Windows 11.

With Windows 11 and 1.16.2I see the same resize issue when manually resizing where tigervnc vncviewer tries to resize to almost the same size desktop before the window is finished resizing. I don't see this when a max'ed window since this appears to be a single operation vs macOS it's animated effect so the resize (like the first case) is trigged too soon?

Also, a full screen resize on Windows 11 unlike macOS does not have that long ID on the DesktopWindow: log line. It's always 0 for windowed and fullscreen switches. So the fullscreen with the long display ID appears to be a macOS only issue.

Reverting back to 1.15.0 on Windows 11 the manual windowed resizes work as expected.

[derekschrock]

Also, testing with tigervnc vncserver/Xvnc (FreeBSD 14.4, tigervnc-server, 1.16.2) everything works fine with 1.16.2 client. I'm guessing this is all a possible non-tigervnc server issue either with tigervnc client or possible all on remote side?

[CendioOssman]

CConnection: SetDesktopSize failed: 4

It looks like wayvnc is fighting us, so I'm not surprised things are misbehaving. We stop trying at this point, to avoid ending up in a loop.

I see that they are using the error code "4", which basically means "maybe things succeeded". This is not something we have handling for at the moment as it is more complex to deal with.

Ideally, wayvnc is fixed so they can return success to these resize operations, rather than "maybe".

984943658 from the DesktopWindow line. Is this expected? Windowed resizes always have this value as 0.

Yes, display ids can be any number. And the server should be able to deal with it. A client can add new monitors at any time.

[derekschrock]

As you suggested returning 0 the windowed resizes work as expected with 1.16.2 and wayvnc.
Trying to add smarts to wayvnc to accept new id's this also fixes the fullscreen issue.

I'll have to check to see how open neatvnc is to accepting these changes to seem the spec is too loose.

[CendioOssman]

Could you try this patch and see if it works with an unmodified wayvnc:

diff --git a/vncviewer/DesktopWindow.cxx b/vncviewer/DesktopWindow.cxx
index b9cccdbcd..4a43758b1 100644
--- a/vncviewer/DesktopWindow.cxx
+++ b/vncviewer/DesktopWindow.cxx
@@ -34,7 +34,6 @@
 #include <core/time.h>
 
 #include <rfb/CMsgWriter.h>
-#include <rfb/ScreenSet.h>
 
 #include "DesktopWindow.h"
 #include "OptionsDialog.h"
@@ -396,13 +395,10 @@ void DesktopWindow::resizeFramebuffer(int new_w, int new_h)
 }
 
 
-void DesktopWindow::setDesktopSizeDone(unsigned result)
+void DesktopWindow::setDesktopSizeDone(unsigned /*result*/)
 {
   pendingRemoteResize = false;
 
-  if (result != 0)
-    return;
-
   // We might have resized again whilst waiting for the previous
   // request, so check if we are in sync
   remoteResize();
@@ -1432,6 +1428,12 @@ void DesktopWindow::remoteResize()
       (layout == cc->server.screenLayout()))
     return;
 
+  // Have we already requested this size?
+  if ((width == lastResizeWidth) &&
+      (height == lastResizeHeight) &&
+      (layout == lastResizeLayout))
+    return;
+
   vlog.debug("Requesting framebuffer resize from %dx%d to %dx%d",
              cc->server.width(), cc->server.height(), width, height);
 
@@ -1447,6 +1449,9 @@ void DesktopWindow::remoteResize()
 
   pendingRemoteResize = true;
   gettimeofday(&lastResize, nullptr);
+  lastResizeWidth = width;
+  lastResizeHeight = height;
+  lastResizeLayout = layout;
   cc->writer()->writeSetDesktopSize(width, height, layout);
 }
 
diff --git a/vncviewer/DesktopWindow.h b/vncviewer/DesktopWindow.h
index af1b7474d..375b4b64c 100644
--- a/vncviewer/DesktopWindow.h
+++ b/vncviewer/DesktopWindow.h
@@ -28,6 +28,8 @@
 
 #include <FL/Fl_Window.H>
 
+#include <rfb/ScreenSet.h>
+
 namespace rfb { class ModifiablePixelBuffer; }
 
 class CConn;
@@ -142,6 +144,8 @@ private:
 
   bool pendingRemoteResize;
   struct timeval lastResize;
+  int lastResizeWidth, lastResizeHeight;
+  rfb::ScreenSet lastResizeLayout;
 
   bool keyboardGrabbed;
   bool mouseGrabbed;

[derekschrock]

Looks good for windowed resizes. You're not expecting this to fix fullscreening correct?

[derekschrock]

I crated this over the weekend not knowing you were working on the first steps to supporting 4 status.

any1/neatvnc#173

If this makes it to master I can close it.

[CendioOssman]

Looks good for windowed resizes. You're not expecting this to fix fullscreening correct?

Right, sorry, this was indeed just for the chained resizes. Nothing about screen ids.

I crated this over the weekend not knowing you were working on the first steps to supporting 4 status.

This fix for TigerVNC is nice to have regardless, as there are other servers using that status. E.g. QEMU.

[derekschrock]

I'm not sure if it's something to worry about even though it's back to the fullscreen issue, with this patch going full screen with wayvnc appears to send a endless loop of resizes back to the server due to the invalid display (invalid layout 3). Don't know if this was expected.