monitorv2 + hyprctl keyword monitor disable causes all Wayland clients to crash

[AlJohri]

Bug: hyprctl keyword monitor disable crashes all Wayland clients when monitorv2 has a specific output rule

Description

When a monitorv2 { } block has a specific output = <name> matching the monitor being disabled, running hyprctl keyword monitor "<name>,disable" crashes all Wayland clients with "error in client communication".

A catch-all monitorv2 { output = } works fine.

Environment

• Hyprland version: 0.53.1 (commit ab1d80f)
• OS: Arch Linux

Minimal Reproduction

Requirements: Two monitors (so you can disable one safely)

Config that WORKS (catch-all only):

# ~/.config/hypr/monitors.conf
monitorv2 {
  output =
  mode = preferred
  position = auto
  scale = 1
}

hyprctl reload
hyprctl keyword monitor "eDP-2,disable"  # use your monitor name

Result: Monitor disables, all clients keep running ✅

Config that CRASHES (specific output rule):

# ~/.config/hypr/monitors.conf
monitorv2 {
  output = eDP-2
  mode = preferred
  position = auto
  scale = 1
}

monitorv2 {
  output =
  mode = preferred
  position = auto
  scale = 1
}

hyprctl reload
hyprctl keyword monitor "eDP-2,disable"  # use your monitor name

Result: All Wayland clients crash ❌

Debug Log (with debug:disable_logs = false)

DEBUG ]: Hyprctl: keyword monitor : eDP-2,disable
DEBUG ]: Applying monitor rule for eDP-2
DEBUG ]: onDisconnect called for eDP-2
DEBUG ]: Monitor eDP-2 -> destroyed all render data
DEBUG ]: Disconnecting Monitor eDP-2 was on workspace 2
DEBUG ]: Removed monitor eDP-2!
DEBUG ]: moveWorkspaceToMonitor: Moving 2 to monitor 1
DEBUG ]: moveWorkspaceToMonitor: Plugging gap with new 3
ERR ]: BUG THIS: No pMonitor for new workspace in createNewWorkspace
DEBUG ]: moveWorkspaceToMonitor: Plugging gap with existing 3
DEBUG ]: Destroying workspace ID 2
DEBUG from aquamarine ]: drm: Disabling output eDP-2
...
DEBUG ]: Applying monitor rule for eDP-2                          <-- Monitor gets RE-ENABLED immediately!
DEBUG from aquamarine ]: drm: Modesetting eDP-2 with 2560x1600@165.00Hz
DEBUG ]: Added new monitor with name eDP-2 at [3440, 0]

Errors during crash:

ERR ]: BUG THIS: No pMonitor for new workspace in createNewWorkspace
WARN ]: [XDGShell.cpp:412] wl_surface destroyed before its xdg_surface role object
ERR ]: onWindowRemovedTiling node null?

Analysis

The log shows that:

1. The disable command is issued
2. The monitor is disconnected and removed
3. Then the monitorv2 rule immediately re-enables it (Applying monitor rule for eDP-2)
4. This rapid disconnect/reconnect cycle causes the client crashes

With monitor = ... (v1 syntax), this re-enable doesn't happen and disable works correctly.

Notes

• Using monitor = eDP-2, preferred, auto, 1 (v1 syntax) works fine
• The crash affects ALL Wayland clients, not just those on the disabled monitor
• The monitor is shown in the log as being re-enabled immediately after disable

Workaround

Use monitor = ... (v1) syntax instead of monitorv2 { } for monitors you need to disable.

[AlJohri]

Additional: journalctl output

The "error in client communication" messages appear in journalctl (from uwsm_hyprland.desktop), showing the moment clients crash:

$ journalctl --user | grep -E "error in client"

Jan 15 13:28:23 framework16 uwsm_hyprland.desktop[3278]: error in client communication (pid 2067151)
Jan 15 13:28:23 framework16 uwsm_hyprland.desktop[3278]: error in client communication (pid 2078699)
Jan 15 13:28:23 framework16 uwsm_hyprland.desktop[3278]: error in client communication (pid 2078299)

These PIDs correspond to the crashed Wayland clients (ghostty, chromium, etc.).

[superpupervlad]

This is definetely a bug and Hyprland should not crash with this command. But according to this discussion when you use monitorv2 in the config you should disable monitor with hyprctl keyword monitorv2[DP-1]:disabled 1

[EvilLary]

Hmm I feel like this is my doing :(, could you try #13154 and see if it's fixed

[ogabriel]

have the same problem, in my case I have the LID configs, and when I close and open the laptop lid, everything crashes

this happened in the past, like 1 year ago, then it started not being a problem anymore, and now this problem seems very similiar.

[Sandruin]

Hitting the same "connect → all Wayland clients die" pattern on 0.55.0 (so post- #13154), but triggered by a physical plug, not hyprctl ... disable. Plugging in my third monitor over HDMI emits two udev events back-to-back - aquamarine processes them as disconnect then connect on the same connector within milliseconds, and the new monitor's wl_output global is advertised then removed before clients finish binding. All clients attached to the registry die with Protocol error.

Clients killed at the plug moment (id 71 = the new monitor's own wl_output)

ksecretd: wl_registry#2: error 0: global wl_output (71) is unavailable nextcloud: wl_registry#2: error 0: global wl_output (71) is unavailable vicinae: wl_registry#2: error 0: global wl_output (71) is unavailable XWAYLAND: wl_registry#2: error 0: global wl_output (71) is unavailable XWAYLAND: failed to dispatch Wayland events: Protocol error kwalletd6: The Wayland connection experienced a fatal error: Protocol error xdg-desktop-portal-gtk: Error 71 (Protocol error) dispatching to Wayland display. blueman-applet / blueman-tray: Error 71 (Protocol error) polkit-kde-authentication-agent-1: fatal error: Protocol error Hyprland log: ~13 error in client communication (pid …) lines, one per killed client. Hyprland itself stays up.

Affected this session: Firefox (via XWayland), XWayland, kwalletd6, ksecretd, vicinae, nextcloud, blueman-applet, blueman-tray, xdg-desktop-portal-gtk, polkit-kde-agent.

Aquamarine DRM trace, one plug cycle

drm: Got a hotplug event for /dev/dri/card1 drm: Connector HDMI-A-1 disconnected drm: Disabling output HDMI-A-1 drm: Connector HDMI-A-1 is not connected, removing old crtc 267 drm: Got a hotplug event for /dev/dri/card1 drm: Connector HDMI-A-1 connected drm: Connecting connector HDMI-A-1, CRTC ID 267 drm: Modesetting HDMI-A-1 with 1920x1080@75.00Hz [×4 during settling]

Environment:
Hyprland 0.55.0 (af923e3, tag v0.55.0)
Aquamarine 0.11.0, Hyprutils 0.13.1, Hyprgraphics 0.5.1, Hyprlang 0.6.8
Arch, kernel 7.0.5-arch1-1, launched via uwsm

Monitors: eDP-1 Caltech 2560×1600 scale 1.6 @ 0,0; DP-1 Dell P2723DE 2560×1440 @ -2560,-360; HDMI-A-1 MSI MD271P 1920×1080@75 @ -4480,-360 (the one plugged).

Ruled out: wildcard monitor=,… fallback (removed), 75Hz refresh rate →happens on 60Hz too, geometry mismatch (y-aligned MSI to Dell, silenced pixman warnings, didn't help), 0.54.3 → 0.55.0 upgrade, modeset failure (modeset succeeds). 100% reproducible on plug-in.

[pbmarcano]

Still reproducing on 0.56.2, and also through the new Lua config provider (configProvider: lua), not just monitorv2 blocks. The trigger here needs no hyprctl call at all: closing a laptop lid while docked, same as @ogabriel above. The compositor's own clamshell handling disables the internal panel, and that is enough.

Hyprland 0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f (v0.56.2, 2026-08-05)
wayland 1.26.0, Arch Linux, Intel Meteor Lake (i915), Omarchy 4.0.0
Monitors: eDP-1 (internal 1920x1200) + LG UltraFine 5K over DP/Thunderbolt

The Lua equivalent of a specific-output monitorv2 block is hl.monitor({ output = "eDP-1", ... }), and it behaves identically.

Confirming the catch-all vs specific-output claim

I can corroborate the original report. Same machine, same trigger, only the config differed — and I went back and forth over several lid cycles:

Config	Result of a lid close
Catch-all only — hl.monitor({ output = "", ... })	One client died (a Qt shell). XWayland survived, session stayed usable
Catch-all + hl.monitor({ output = "eDP-1", ... })	Mass kill: XWayland, foot, hyprsunset, xdg-desktop-portal-{gtk,hyprland}, fcitx5, electron

Adding the specific-output rule reliably produced the mass kill; removing it made lid cycles clean again and they have stayed clean since. So on 0.56.2 an explicit output rule for the monitor being disabled is the difference between losing one client and losing the session.

Journal at the moment of one lid close:

systemd-logind[896]: Lid closed.
fcitx5[2009]: wl_registry#2: error 0: global wl_output (81) is unavailable
uwsm_hyprland.desktop[2014]: XWAYLAND: wl_registry#2: error 0: global wl_output (81) is unavailable
xdg-desktop-portal-gtk[2150]: Error 71 (Protocol error) dispatching to Wayland display.
voxtype-osd-gtk4[2080]: Error 71 (Protocol error) dispatching to Wayland display.
electron[2003]: Error 71 (Protocol error) dispatching to Wayland display.
omarchy-shell[1973]: WARN: The Wayland connection experienced a fatal error: Protocol error
uwsm_hyprland.desktop[1907]: error in client communication (pid ...)
...one per killed client. Hyprland itself stays up.

It fires on both edges of the lid switch — once on close and again on open, ~7s apart.

Two notes that may help triage

1. Survival is timing-dependent, consistent with the registry bind race. Two foot instances were running; one died, one did not. Clients that segfault rather than exit cleanly do so inside registry dispatch — a Qt shell (with QT_QPA_PLATFORMTHEME=gtk3, so GTK is loaded in-process) and Chromium both crashed in libgdk-3 → libffi → wl_display_dispatch_queue_pending.

2. The XWayland non-recovery is the most damaging part, as Removing a monitor can kill Xwayland and other clients with fatal 'global wl_output is unavailable' protocol error (registry bind race) #15635 also noted. Once XWayland dies it is never respawned, yet DISPLAY=:0 and /tmp/.X11-unix/X0 remain, so every X client blocks forever on connect. Chromium hangs in xdg-settings → xprop -root and launches with no window; hung xprop processes then accumulate. Only a full logout/login recovers it. The hyprctl keyword monitorv2[...]:disabled 1 workaround suggested earlier does not apply when the trigger is a lid switch.

Practical consequence for users

The only safe configuration I found is a catch-all rule with no per-output rules at all. That rules out pinning a laptop panel to 0x0, so after every clamshell cycle the internal display is re-appended to the right of the external one (position = "auto" being order-dependent, and the first monitor always landing at (0,0)). Correct placement and not losing the session are currently mutually exclusive on a docked laptop.

Related: #15635 described the same registry bind race but was auto-closed by the issue bot rather than triaged.

Filed by Claude Opus 5 via Claude Code, on behalf of the machine's owner.

[pbmarcano]

Follow-up to my earlier report, with a root cause and a config-side mitigation for the MST-fold case, in case it helps others hitting this.

Why reloads kept destroying the output: the reload reconciler skips any monitor whose live state already matches its rule (COMPARISON_FULL_MATCH in MonitorRuleManager::ensureMonitorStatus) — but hl.get_monitors() hides mirrored/disabled monitors, so a config that folds an MST tile cannot re-register the mirror rule during a reload. The reconciler then un-mirrors the tile and the config's re-fold destroys the freshly created wl_output, triggering the registry race described here.

Mitigation that works today (verified on Hyprland 0.56.2: repeated reloads and theme switches, the tile never left mirror state, zero client deaths): persist the fold decision ("<dead-tile> <primary>") to a file in $XDG_RUNTIME_DIR when folding, and re-register the identical hl.monitor({ output = ..., mirror = ... }) rule at every config load, after the catch-all. The live state then matches the rule and reload never touches the tile. The rule must have exactly the same field shape both times, since the skip requires a full field-by-field match.

PR #14693 (hl.get_monitors({ all = true })) would make the state file unnecessary — commented there with details. The underlying hazard (a destroyed wl_output fataling clients mid-registry-dispatch, and XWayland never respawning) of course remains.