After a monitor disconnects and reconnects, some X11 windows stop updating on screen until resized #1515

Environment

• Windows build: 10.0.26200.9457
• WSL 2.7.14.0, kernel 6.18.33.2-2
• WSLg 1.0.73.2 (Weston 9.0.0, FreeRDP 2.4.0), MSRDC 1.2.7214
• Distro: Ubuntu. The apps are X11 (Xwayland): Tk (Python tkinter) and Qt 6.11 (PyQt6, xcb platform)
• Two 3840x2160 monitors side by side, Windows display scaling 150%, connected through a DisplayPort KVM switch

Summary

After the second monitor disconnects and reconnects (switching the KVM away and back), some X11 windows on that monitor stop updating on the Windows desktop. The application keeps painting, and the X server holds the new contents, but the window on screen keeps showing the old picture indefinitely. Resizing the window, or perhaps moving the window, even by one pixel and back, makes it update again. Other windows on the same monitor are unaffected, and which ones stall seems arbitrary.

Steps to reproduce

1. Open several X11 windows on the second monitor, with content that changes continuously. Ours show clocks that tick every second.
2. Press Win+D to minimize everything, then switch the KVM to another computer so both monitors disconnect from Windows.
3. Wait about two minutes, switch back, and press Win+D to restore.
4. Some of the windows now show frozen content. Resizing one un-freezes it.

Win+D alone (minimize and restore without disconnecting a monitor) does not reproduce it.

Evidence

For three windows on the reconnected monitor, we checked whether the clock region changed over 4 s (8 samples), in two places:

• X side: XGetImage on the application's window
• Windows side: a screen capture of the same area

Before the switch, all three showed 4/7 on both sides. After xdotool windowsize <id> <w+1> <h> and back, B and C showed 4/7 on both sides again.

Window positions agree between the two sides: each RAIL window's GetWindowRect equals the X client position minus the Weston frame. So nothing was moved; the updates simply aren't forwarded.

The relevant weston.log lines (monitor 2 detached, then re-attached under a new head):

[07:49:19.850] Client: DisplayLayoutChange: monitor count:0x1
[07:49:19.850]  rdpMonitor[0]: x:0, y:0, width:1600, height:900, is_primary:1
[07:49:19.850] Head detaching: rdp-3, index:3, is_primary: 0
[07:49:20.154] Client: DisplayLayoutChange: monitor count:0x1
[07:49:20.154]  rdpMonitor[0]: x:0, y:0, width:3840, height:2160, is_primary:1
[07:51:31.294] Client: DisplayLayoutChange: monitor count:0x2
[07:51:31.294] Head attaching: rdp-5, index:5, is_primary: 0
[07:51:31.294] Output 'rdp-5' enabled with head(s) rdp-5

No shell_reposition_view_on_workarea_change lines appear for these windows.

Possibly related

On another occasion, with the monitors powered off overnight by the Windows display-off timeout, Weston crashed (SIGSEGV in rdp-backend.so) during the DisplayLayoutChange when the display woke. It reported three monitors: a 3840x2160 primary at 100% scaling, alongside the two real ones. Every X11 client died with it. From the kernel log:

weston[244]: segfault at a4 ip 0000769074257190 sp 00007ffe564310f8 error 4 in rdp-backend.so[c190,769074251000+18000]

and WSLGd: pid 12 terminated with signal 11, /usr/bin/sh -c /usr/bin/weston --backend=rdp-backend.so ...

Workaround

Resize each affected window by one pixel and back after a monitor change (we now automate this by watching /mnt/wslg/weston.log for DisplayLayoutChange).