Intellihide panel-hide animation on fullscreen transition breaks presentation to the fullscreen client (freeze with OpenGL, segfault with Vulkan)

[ticpu]

Things to do first

• Confirm that the problem persists when Dash-to-Panel is the only enabled extension.
• Look for Dash-to-Panel errors in the log (nothing is logged — see below).
• Search existing opened and closed issues.

Describe the bug

With Panel Intellihide enabled, taking a window fullscreen breaks presentation to that window. The compositor and the rest of the desktop stay fully responsive. Only the fullscreen client is affected, and the failure mode depends on which graphics API the client uses:

• OpenGL clients: the window renders a few frames (~200 ms), then the surface stops updating. Audio continues, so decoding is still running, only presentation is blocked. Leaving fullscreen resumes playback normally.
• Vulkan clients: the client segfaults instead of stalling.

The trigger is the panel-hide animation, not the fullscreen state change itself. Holding the pointer over the panel so intellihide does not hide it, then going fullscreen, avoids the problem entirely and reliably. This is the cleanest handle I found on the bug.

Disabling Intellihide (keeping Dash-to-Panel enabled) avoids it. Disabling Dash-to-Panel avoids it. No other extension is involved, reproduced with Dash-to-Panel as the only enabled extension.

Affected applications are anything that goes fullscreen with continuously updating content: mpv, Remmina (the entire remote-desktop surface stops updating, including its own UI elements), Discord (video stops). Steam games are unaffected, which is consistent with gamescope-hosted games not producing the same fullscreen transition.

How to reproduce

1. Enable Dash-to-Panel with Panel Intellihide on, all other extensions disabled.
2. Open a video in mpv (windowed) and let it play.
3. Move the pointer away from the panel and press f to go fullscreen.
4. The video freezes within ~200 ms while audio continues. Leaving fullscreen resumes it.

Negative control: repeat step 3 while keeping the pointer over the panel so it does not hide. No freeze.

What I ruled out

Since the failure is invariant across every layer below the compositor, none of these are the cause:

	direct scanout on	direct scanout off
OpenGL (--vo=gpu --gpu-api=opengl)	freeze, recovers on unfullscreen	freeze, recovers on unfullscreen
Vulkan (libplacebo, default)	segfault	segfault

• MUTTER_DEBUG_DISABLE_DIRECT_SCANOUT=1 (verified present in the running gnome-shell's /proc/<pid>/environ) changes nothing.
• Rendering on the other GPU via DRI_PRIME=1 changes nothing.
• Not specific to mpv: Remmina (a GTK app with no video decoding involved) exhibits the same stall, with its entire surface including UI elements ceasing to update.
• Nothing is logged by gnome-shell or Dash-to-Panel while the fault occurs.

The Vulkan segfault lands at a byte-identical address in NVIDIA's userspace driver on every occurrence, so it is deterministic rather than a race:

Stack trace of thread (vo):
#0  libnvidia-glcore.so.610.43.03 + 0xcf97a6
#1  libnvidia-glcore.so.610.43.03 + 0xcfa4eb
#2  libnvidia-glcore.so.610.43.03 + 0xcfafae
#3  libvulkan.so.1 + 0x56215
#4  libplacebo.so.360 + 0xbf682
#5  libplacebo.so.360 + 0xc061c
#6  mpv + 0x129dca

I read the driver crash as a downstream symptom rather than the cause: the OpenGL path and Remmina fail paths fail on the same trigger without involving Vulkan at all.

Related issues

I asked Claude to search for other issues, here is what I found could be related.

• Dash to Panel breaks VRR #2309 "Dash to Panel breaks VRR" — same component, reported as lost VRR. Two reporters isolated it to Dash-to-Panel alone. One notes that toggling the overview fixes it for the current session; that does not work here. Once the fullscreen surface is wedged, nothing recovers it short of leaving fullscreen — toggling the overview and making the panel reappear both have no effect. Stale, undiagnosed.
• Direct scanout / VRR stops working after disabling secondary monitor #2506 "Direct scanout / VRR stops working after disabling secondary monitor" — reporter edited to say it is an intellihide issue, and reproduces with a fullscreen video player. Suggests a milder form of this bug where scanout silently falls back to compositing instead of stalling. Includes a useful verification method: ALT+F2 → lg → flags → enable PAINT_DAMAGE_REGION under ClutterDrawDebugFlag; a red overlay on fullscreen video indicates compositing is not being bypassed.
• Shell freeze when revealing panel #1934 "Shell freeze when revealing panel" — mpv fullscreen + intellihide, closed as stale. Distinct from this report: there the whole shell locks up and requires a VT re-login. Here the shell stays responsive and only the fullscreen client is affected.

Linux distribution and version

Arch Linux, kernel 7.1.5-arch1-2 (started a while back while still using 6.x)

GNOME Shell version

GNOME Shell 50.3 (Wayland), mutter 50.3

Dash-to-Panel version

73

Where was Dash-to-Panel installed from?

Arch package gnome-shell-extension-dash-to-panel 73-1 (upstream v73, installed to /usr/share/gnome-shell/extensions/)

Additional info

Dual-GPU system, both driving a display simultaneously:

• NVIDIA RTX 3090 (nvidia / nvidia-open-dkms 610.43.03, nvidia_drm modeset=1) — DP-5
• AMD Raphael iGPU (amdgpu) — DP-1

The dual-GPU configuration may be why this presents as a hard stall here while other reporters see only degraded scanout/VRR.