Comment 1 William Sjöblom 2022-01-13 14:25:37 CET

To clarify comment 0, you likely have to press Win+P several times to enter screen mirroring.

Comment 2 William Sjöblom 2022-01-13 14:41:38 CET

Also note that, since I'm currently working remotely, I cannot test if this is an issue on platforms other than Linux.

Comment 3 William Sjöblom 2022-01-13 16:06:27 CET

I can now confirm that we get the same behavior for XFCE and X11 when performing the above steps.

Comment 4 William Sjöblom 2022-01-13 16:43:23 CET

On XFCE I also managed to provoke the opposite scenario when going from "mirror" to "extend" resulting in the session not expanding properly. Just as before we get the "Invalid screen layout" error in the logs.

Sadly, I have not been able to reproduce this more than once. I have a weak suspicion that it may be related to the display layout that XFCE chooses when going from "mirror" to "extend" which, to me, seems rather arbitrary.

Comment 5 William Sjöblom 2022-01-18 12:20:29 CET

I have also been able to reproduce the issue with KDE Plasma.

Comment 6 William Sjöblom 2022-01-18 12:24:12 CET

I have also attempted to reproduce the issue on macOS and Windows without success, so this issue is likely exclusive to Linux. This kind of smells like an upstream issue, so a reasonable way forward would be to write up a minimal test case such that this can be reported upstream.

Comment 7 William Sjöblom 2022-01-18 14:29:07 CET

I have now also tested mirroring on MATE using xrandr and done some additional digging for KDE Plasma. Minimizing the client and configuring the mirroring in a local terminal/settings application works just as well as doing it from inside the session for provoking the bug. So this seems to be a much more general issue than initially thought.

Worth noting is that the same "Invalid screen layout computed for resize request" message is logged every time I have been able to provoke this issue.

Regarding comment 6, some additional testing is needed before drawing any conclusions about this being an upstream issue. We should start out by determining why the "Invalid screen layout computed" assertion fails and potentially add in some permanent debug traces during this layout validation.

Comment 8 William Sjöblom 2022-01-19 09:16:28 CET

With vncviewer running with verbose logging enabled, I got the following context to the "Invalid screen layout" error.

> 2022-01-18T16:29:05: vncviewer[E]: Tue Jan 18 16:29:05 2022
> 2022-01-18T16:29:05: vncviewer[E]:  DesktopWindow: Requesting framebuffer resize from 3840x1200 to 1920x1200
> 2022-01-18T16:29:05: vncviewer[E]:  DesktopWindow: 2 screen(s)
> 2022-01-18T16:29:05: vncviewer[E]:  DesktopWindow:      719885386 (0x2ae8944a): 1920x1200+0+0 (flags 0x00000000)
> 2022-01-18T16:29:05: Last line was repeated 1 time(s).
> 2022-01-18T16:29:05: vncviewer[E]:  DesktopWindow: 
> 2022-01-18T16:29:05: vncviewer[E]:  DesktopWindow: Invalid screen layout computed for resize request!

We have two identical screens in our layout, which is not allowed. I have implemented a fix that will be upstreamed and likely followed by a new TigerVNC vendor drop.

Comment 9 William Sjöblom 2022-01-19 12:43:49 CET

A PR to upstream TigerVNC has now been made https://github.com/TigerVNC/tigervnc/pull/1411

Comment 10 Samuel Mannehed 2022-01-20 14:30:22 CET

The fix has been merged upstream and we will do a vendordrop to bring it to ThinLinc. The last vendordrop of TigerVNC was 2022-01-12, and the changes (aside from the fix) made since that are:

 * SELinux: restore SELinux context in case of different policies
 * Fix handling of VMware cursors

Neither of the above should affect ThinLinc.

Comment 13 Samuel Mannehed 2022-01-20 16:31:54 CET

The changed code is in remoteResize(), which means we have to test session resizing of all types, not only concerning mirroring. We should probably test screen hotplugging as well.

There is no OS-specific code here, but since the different platforms handle screens locally in quite different ways we still need to test on Windows, Linux and macOS.

Comment 14 William Sjöblom 2022-01-21 17:22:08 CET

We have now reproduced the bug using 4.14.0beta1 and can no longer reproduce it using client build #2321 running on Fedora 33.
 
We also did some regression testing on the same machine, verifying that the following still works as intended:
- Server-side resizing (in both windowed and full-screen mode and when mirrored in one of these modes)
- Monitor hotplug
  - Mirroring
  - Changing monitor resolution
  - Changing monitor position

Marking as resolved.

Comment 15 Samuel Mannehed 2022-01-21 19:29:42 CET

I have tested build 2321 on Windows 10 now with 3 monitors:

 * Windowed mode & maximized
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
 * Full screen on all monitors
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
   - hotplug
 * Full screen on selected monitors (all)
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
   - hotplug
 * Mirroring
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
   - hotplug

Comment 16 Samuel Mannehed 2022-01-24 17:31:16 CET

I have tested build 2321 on macOS 12 (intel) now with 3 monitors:

 * Windowed mode (maximized doesn't really exist it seems)
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease

The below "works" but I encountered bug 7824 a lot with the screen setup I initially tested with. I had 3 different monitors with different resolutions and one of them was in portrait orientation. When changing the screen layout while in full screen you run into that bug a lot, especially when changing the left or middle monitors.

Changing size, layout or orientation of the right-most monitor didn't cause any issues. And using 3 monitors with the same orientation and resolution made all issues go away.

It's also worth noting that sometimes the desktop environment in the session can have bugs on this topic. If you think this might be the case, it's best to test without a desktop environment, i.e. xterm with metacity in the session.

 * Full screen on all monitors
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
   - hotplug
 * Full screen on selected monitors (all)
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
   - hotplug
 * Mirroring
   - Client side size increase
   - Client side size decrease
   - server side size increase
   - server side size decrease
   - hot-plug

With that, we have tested all major platforms.