## Summary

On a fresh Omarchy 4.0.2 ("Quattro") install with a hybrid Intel+NVIDIA laptop, GPU-accelerated app windows (Electron/CEF, GTK4) never receive a usable compositor-side surface. Reproduced with **three unrelated apps using three different toolkits/sandboxing methods**, while simple apps (terminal) and already-open windows are unaffected. Not fixed by a reboot.

## System

- Omarchy 4.0.2-1 (fresh install, first boot same day as this report)
- Hyprland 0.56.2 (commit `efb50993780079460b0cbed1363e2166a2de1d9f`)
- aquamarine 0.14.0, Hyprutils 0.14.1 (aquamarine built against 0.14.0 — version mismatch noted, unconfirmed if related)
- xdg-desktop-portal-hyprland 1.4.1-1, xdg-desktop-portal 1.22.1-2
- nvidia-open-dkms 610.57.04-8, nvidia-utils 610.57.04-1 (rebuilt same day as this report, against kernel 7.1.9-arch1-2)
- Kernel 7.1.9-arch1-2
- GPU: Intel Tiger Lake (i915, drives both physical displays: eDP-1 + HDMI-A-1) + NVIDIA RTX 2050 (dGPU, **zero display outputs** — dmesg: `nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes`)
- `nvidia_drm.modeset` confirmed = `1`

## Reproduction cases

**1. Brave's screen-share picker (`hyprland-preview-share-picker`, GTK4)**
Configured via `custom_picker_binary` in `xdph.conf`. Process launches, logs "presenting window", successfully renders screenshot previews via the compositor's screencopy protocol (`wlr_screencopy_manager_v1`) — but the window **never appears in `hyprctl clients` or `hyprctl layers`**. It is completely invisible to the compositor: can't be focused, clicked, or interacted with. Reproduced with the custom picker removed (falls back to portal's built-in picker) — same result, all apps affected identically regardless of picker binary.

**2. Spotify (native Arch package, `spotify-1:1.2.96.518-2`, bundled CEF/Chromium 146)**
Browser process and GPU process spawn correctly: `--ozone-platform=wayland`, `--render-node-override=/dev/dri/renderD129` (correctly targets the Intel iGPU that actually has displays attached, not NVIDIA). No crash, no error, no dmesg output. Confirmed via `gdb -p <pid> -batch -ex "thread apply all bt"`: **main UI thread is deadlocked forever in `recvmsg()` inside `libxcb`, called from `libcef.so`** — i.e. it made a synchronous X11 (XWayland) request and never got a reply. GPU process itself is idle/healthy (all threads in normal `epoll_wait`/`futex_wait`/`ppoll` idle-loop states).

**3. Spotify (Flatpak, `com.spotify.Client`, different bundled CEF/runtime, bwrap+portal sandboxing)**
Completely different build and sandbox. Same end result: window never appears. Different failure mode though — main thread spins at ~99% CPU indefinitely instead of idling. (Backtrace inconclusive: gdb couldn't resolve symbols across the bubblewrap mount-namespace boundary from the host.)

## What's unaffected

- `kitty` terminal windows: map and work normally.
- Chromium browser windows already open before the issue was investigated, and default `chromium` package (no forced `--ozone-platform=wayland`, runs via plain XWayland): work normally.

## Ruled out during investigation

- GPU driver crash: no relevant errors in `dmesg`.
- `nvidia_drm.modeset`: confirmed enabled.
- Cross-GPU dma-buf mismatch: ruled out — GPU processes correctly select the Intel render node (the GPU that actually has outputs), not NVIDIA.
- Corrupted app cache: cleared Spotify's 4.2GB cache dir entirely, no change.
- Forcing `--ozone-platform=x11`: Spotify's CEF build has no working X11 fallback (exits instantly, no window, no error).
- Forcing `--ozone-platform=wayland` explicitly: still hangs, same as default.
- `LIBVA_DRIVER_NAME` override (`nvidia` → `iHD`, since Intel is the actual render GPU): made things worse (instant silent exit), reverted.
- Xwayland startup warnings `[dix] couldn't enable device 10/11/12`: confirmed via `xinput list` these are unrelated virtual tablet stylus/eraser/cursor devices, not a plausible cause.
- `xrandr --listproviders`: returns 0 providers, rules out an NVIDIA-as-zero-output-RandR-provider theory.
- A full reboot: does not fix it (rules out transient first-boot/daemon state).

## Question for maintainers

Given three unrelated toolkits (GTK4, native CEF, Flatpak-sandboxed CEF) all fail to get a working compositor-side surface on the same fresh install, while simple/pre-existing windows are fine — does Hyprland 0.56.2 / aquamarine 0.14.0 have a known regression in initial buffer/surface commit handling for new GPU-accelerated Wayland clients, particularly on hybrid Intel+NVIDIA (Optimus-style, NVIDIA has no outputs) setups? Happy to gather more diagnostics (full Hyprland debug log, `WAYLAND_DEBUG=1` trace, etc.) if pointed at what would help.