X11 session shows unwanted "Default Monitor" dialog after suspend/resume with libxfce4windowing 4.20.6

Related issue:

Captura_de_pantalla_2026-06-02_20-21-02

Affected versions:

  • libxfce4windowing 4.20.6
  • xfdesktop 4.20.2
  • xfce4-settings 4.20.4 (indirectly, due to display identification conflicts)

Fixed by:

  • Disabling the fallback monitor creation in X11 sessions (see patch below)

Problem Description

After upgrading from libxfce4windowing 4.20.5 to 4.20.6, an unwanted dialog window appears minimized every time the system wakes up from suspend. The window is related to display settings and seems to be triggered by xfdesktop misinterpreting a monitor change event.

This issue does not occur with libxfce4windowing 4.20.5. It is reproducible on X11 sessions (Wayland not tested, but the root cause likely affects both).

Root Cause Analysis

The regression was introduced in libxfce4windowing 4.20.6 by the addition of a fallback monitor mechanism in xfw-monitor-x11.c.

When the system resumes from suspend, the function enumerate_monitors() sometimes fails to detect any physical monitor (possibly due to timing issues during the graphics stack reinitialization). In 4.20.5, this would simply return an empty monitor list. In 4.20.6, a new function create_fallback_monitor() is called to create a dummy monitor named "Default Monitor".

The presence of this fallback monitor is then propagated to xfdesktop and xfce4-settings. Due to a pre-existing, long-standing disagreement between these two components on how display IDs are identified (especially noticeable in Wayland sessions, but also affecting X11), xfdesktop interprets the fallback monitor as a legitimate display change and triggers the unwanted configuration dialog.

Why this fix is safe for X11

In a properly functioning X11 session, there should always be at least one physical monitor detected after the graphics stack is fully initialized. The only scenario where monitors == NULL occurs is the transient timing window during suspend/resume.

Disabling the fallback monitor creation in X11 (by making the condition always false) simply restores the original behavior of 4.20.5. It does not break normal monitor detection or hotplugging, because those code paths rely on real monitor enumeration via XRandR, not on the fallback.

If a system genuinely has no monitors (e.g., headless server), XFCE is not the appropriate desktop environment anyway. The fallback mechanism may still be valuable for Wayland, where monitor enumeration can be more asynchronous, so this patch targets X11 only.

Proposed Patch

The following change disables the fallback monitor creation in X11 sessions:

diff -Naur libxfce4windowing-4.20.6.orig/libxfce4windowing/xfw-monitor-x11.c libxfce4windowing-4.20.6/libxfce4windowing/xfw-monitor-x11.c
--- libxfce4windowing-4.20.6.orig/libxfce4windowing/xfw-monitor-x11.c	2026-04-06 00:17:53.000000000 -0600
+++ libxfce4windowing-4.20.6/libxfce4windowing/xfw-monitor-x11.c	2026-06-06 22:37:50.098293108 -0600
@@ -529,7 +529,7 @@
         XRRFreeMonitors(rrmonitors);
     }
 
-    if (monitors == NULL) {
+    if (FALSE && monitors == NULL) {
         monitors = g_list_append(monitors, create_fallback_monitor(dpy, manager->screen, cur_workspace_num));
     }

Issue was solved after rebuilding libxfce4windowing 4.20.6 with this patch and then restart desktop session.

Alternative implementation (more explicit):

-#ifdef GDK_WINDOWING_X11
-    if (monitors == NULL) {
-        monitors = g_list_append(monitors, create_fallback_monitor(dpy, manager->screen, cur_workspace_num));
-    }
-#endif
+    /* On X11, a fallback monitor should never be needed. The original 4.20.5
+     * behavior was to return an empty list. Creating a dummy monitor here
+     * confuses xfdesktop and xfce4-settings, causing unwanted dialogs after
+     * suspend/resume. See: https://gitlab.xfce.org/xfce/xfdesktop/-/work_items/458
+     */
+    if (FALSE && monitors == NULL) {
+        monitors = g_list_append(monitors, create_fallback_monitor(dpy, manager->screen, cur_workspace_num));
     }

Steps to Reproduce (for maintainers)

  1. Install libxfce4windowing 4.20.6 on an X11-based XFCE session.
  2. Suspend the system (e.g., loginctl suspend or close laptop lid).
  3. Wait a few minutes and wake the system.
  4. Observe that a minimized dialog window (related to display settings) appears.
  5. The issue does not occur with libxfce4windowing 4.20.5

Captura_de_pantalla_2026-06-02_20-21-02

Environment (for reference)

  • OS: ALDOS 1.4.21 (SysVinit, no systemd)
  • XFCE version: 4.20
  • xfdesktop version: 4.20.2
  • libxfce4windowing version: 4.20.6 (patched) / 4.20.5 (working)
  • Windowing system: X11
  • Compositor: xfwm4 4.20.0

Additional Context

This issue is partially a symptom of a deeper, long-standing inconsistency between xfdesktop and xfce4-settings regarding how displays are identified. That underlying problem becomes more visible in Wayland sessions but also affects X11 when unusual monitor events occur (such as the transient state during suspend/resume).

The fallback monitor mechanism was likely introduced to improve Wayland support, but it should be conditional on the windowing system. It is unnecessary and disruptive for X11.

Request

Please consider:

  • Merging the proposed patch (or a cleaner equivalent) to disable fallback monitor creation in X11 sessions.
  • Alternatively, refactoring the fallback mechanism to be Wayland-only, or adding a more robust check (e.g., only create fallback if the system is explicitly configured for headless operation).

Greetings!