https://bugs.kde.org/show_bug.cgi?id=523192
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|Arch Linux |Debian unstable Status|REPORTED |CONFIRMED Ever confirmed|0 |1 --- Comment #4 from [email protected] --- Additional reproduction on AMD hardware with KWin 6.7.4, including a reduced GTK3 testcase and screenshots comparing the compositor output with the actual X11 client contents. Environment: - Debian forky/sid, Plasma/KWin 6.7.4, Wayland session - AMD Fiji (Radeon R9 FURY / NANO Series), amdgpu, Mesa 26.1.6 - Kernel 7.1.12+deb14-amd64; XWayland 24.1.13; GTK 3.24.52 - Remmina 1.4.43, FreeRDP runtime 3.31.1 - Two EIZO EV2436W monitors, [email protected] Hz each, side by side, 100% scale; combined desktop 3840x1200 - No custom KWin window rules Full package versions and display details are in environment.txt. Actual Remmina reproduction: 1. Fully exit Remmina, including the tray instance, and launch with GDK_BACKEND=x11. 2. Connect to an RDP profile with multimon=1, scale=2, resolution_mode=2, force_multimon=0, span=0, and empty monitorids. 3. The connection starts in multi-monitor fullscreen, but initially only a small black rectangle is visible at the upper left. 4. Disable and re-enable fullscreen through the context menu of the task manager's window preview. The same remote desktop then displays correctly across both monitors without reconnecting. Also confirmed with the actual Remmina session: minimizing and restoring the fullscreen connection window fixes the display. To perform this through the taskbar, I had to adjust the task manager's grouping so the fullscreen viewer has its own icon/entry. My default task manager configuration grouped Remmina's main/launcher window and the fullscreen connection window together. Showing them separately allows the fullscreen connection window to be targeted individually for minimize/restore. Reduced testcase and captured evidence: The attached Python/GTK3 probe follows Remmina 1.4.43's initial multimon fullscreen mapping sequence: realize toplevel, show an empty notebook/overlay, append content, then request GDK all-monitor fullscreen from map-event. It contains only a neutral colored grid; no RDP connection is involved. It reproduces the initial visible symptom locally: - 01-initial-composited-screen.png: Spectacle's desktop capture shows a black 200x200 rectangle at the upper left. - 02-initial-client-window.png: ImageMagick's direct capture of that same X11 window, before any fullscreen toggle, contains the complete correctly rendered 3840x1200 grid. - The window already reports geometry 3840x1200 and _NET_WM_STATE_FULLSCREEN / _NET_WM_STATE_FOCUSED. - 03-after-kwin-fullscreen-cycle.png: KWin's own fullscreen action is invoked twice through KGlobalAccel. In this reduced testcase it updates the visible contents but leaves a smaller stale grid at the upper left. Unlike the actual Remmina session above, this does not fully recover the display. The diagnostic screen captures were made with one neutral native-Wayland fullscreen background window per monitor behind the probe, covering unrelated applications. capture.py reproduces that setup and the capture sequence. README.txt explains the files and commands. The screenshots are unedited and contain no remote-desktop data. Additional observation: Omnissa Horizon Client also shows a matching initial dual-monitor fullscreen symptom on this machine (installed package 2603-8.18.0-24120621798). I have not established whether it triggers the same underlying defect. This points to a presentation/synchronization problem, but does not establish which component owns the root cause. Both the external fullscreen-toggle workaround and minimizing/restoring the fullscreen connection window have been verified with Remmina. -- You are receiving this mail because: You are watching all bug changes.
