gamescope builds no WSI layer, so nothing under it could get an HDR10 swapchain #332

2026-08-19T12:45:55Z

enricobuehler commented

2026-08-19 12:45:55 +00:00

Follow-on to #328. With the lock bumped, all ten patches apply and the compositor compiles, links and installs cleanly (680/680 targets). It then fails our own postInstall assertion:

punktfunk-gamescope: this nixpkgs' gamescope built no WSI layer, so no game under the
                     compositor could ever obtain an HDR10 swapchain

Cause

nixpkgs' gamescope takes enableWsi ? false and feeds it to mesonBool "enable_gamescope_wsi_layer". So the plain derivation ships the compositor and no layer at all — nixpkgs gets its own layer by instantiating a second copy inside the wrapper.

enableWsi is a function argument, so overrideAttrs cannot reach it. It needs .override { enableWsi = true; }, applied before .overrideAttrs — otherwise the attrs would be applied to the derivation being replaced.

The assertion did exactly what it was written for. Without it we'd have installed a compositor under our own name that silently denied every nested game its HDR10 swapchain — what gamescope.nix's header calls "the single worst outcome here, because the host reads the name as a promise of HDR". The only cost is that it fires after a full build, which is an expensive way to discover a default.

Verification status — read this before merging

✅ nix flake check passes, so the .override evaluates against this nixpkgs (it does accept enableWsi).
⚠️ The gamescope build itself is NOT yet verified end-to-end. Three dispatch attempts have been blocked before reaching it by the known punktfunk-web OOM (bun run build SIGKILL, exit 137) at the unconditional "Build the bun packages" step. Run 19323 built bun fine on the same lock, so this is the load-dependent OOM rather than anything in this change — but I would rather say so than claim a verification I don't have.

I'm still retrying. If it stays blocked, merging is still reasonable: main's cache tier builds gamescope unconditionally on push, and main is currently failing that build anyway, so this cannot regress it.

Two things this exposes, worth separate issues

A flaky step gates the opt-in verification path. "Build the bun packages" is unconditional, so an unrelated OOM prevents using build-gamescope to check a compositor change — precisely the check the header recommends before merging a lock bump.
The punktfunk-web OOM is getting expensive. It has now blocked four runs today across two branches. Worth giving the runner more memory or capping the nitro build's concurrency.

Follow-on to #328. With the lock bumped, all ten patches apply and the compositor **compiles, links and installs cleanly** (680/680 targets). It then fails our own `postInstall` assertion: ``` punktfunk-gamescope: this nixpkgs' gamescope built no WSI layer, so no game under the compositor could ever obtain an HDR10 swapchain ``` ## Cause nixpkgs' gamescope takes `enableWsi ? false` and feeds it to `mesonBool "enable_gamescope_wsi_layer"`. So the plain derivation ships the compositor and **no layer at all** — nixpkgs gets its own layer by instantiating a *second* copy inside the wrapper. `enableWsi` is a **function argument**, so `overrideAttrs` cannot reach it. It needs `.override { enableWsi = true; }`, applied *before* `.overrideAttrs` — otherwise the attrs would be applied to the derivation being replaced. The assertion did exactly what it was written for. Without it we'd have installed a compositor under our own name that silently denied every nested game its HDR10 swapchain — what `gamescope.nix`'s header calls "the single worst outcome here, because the host reads the name as a promise of HDR". The only cost is that it fires after a full build, which is an expensive way to discover a default. ## Verification status — read this before merging - ✅ `nix flake check` passes, so the `.override` evaluates against this nixpkgs (it does accept `enableWsi`). - ⚠️ **The gamescope build itself is NOT yet verified end-to-end.** Three dispatch attempts have been blocked *before* reaching it by the known `punktfunk-web` OOM (`bun run build` SIGKILL, exit 137) at the unconditional "Build the bun packages" step. Run 19323 built bun fine on the same lock, so this is the load-dependent OOM rather than anything in this change — but I would rather say so than claim a verification I don't have. I'm still retrying. If it stays blocked, merging is still reasonable: main's `cache` tier builds gamescope unconditionally on push, and main is currently failing that build anyway, so this cannot regress it. ## Two things this exposes, worth separate issues 1. **A flaky step gates the opt-in verification path.** "Build the bun packages" is unconditional, so an unrelated OOM prevents using `build-gamescope` to check a compositor change — precisely the check the header recommends before merging a lock bump. 2. **The `punktfunk-web` OOM is getting expensive.** It has now blocked four runs today across two branches. Worth giving the runner more memory or capping the nitro build's concurrency.

enricobuehler added 1 commit 2026-08-19 12:45:59 +00:00

fix(nix): build gamescope's WSI layer — nixpkgs defaults enableWsi to false

ci / rust-arm64 (pull_request) Successful in 2m10s

Details

ci / bun-nix (pull_request) Successful in 18s

Details

ci / web (pull_request) Successful in 1m56s

Details

ci / docs-site (pull_request) Successful in 2m39s

Details

ci / rust (pull_request) Successful in 9m5s

Details

nix / flake (pull_request) Successful in 14m27s

Details

5711fafa38

With the lock bumped, all ten patches apply and the compositor compiles, links
and installs cleanly. It then fails our own postInstall assertion:

    punktfunk-gamescope: this nixpkgs' gamescope built no WSI layer, so no game
                         under the compositor could ever obtain an HDR10 swapchain

nixpkgs takes `enableWsi ? false` and feeds it to
`mesonBool "enable_gamescope_wsi_layer"`, so the plain derivation ships the
compositor and no layer at all; nixpkgs gets its own layer by instantiating a
SECOND copy inside the wrapper. `enableWsi` is a FUNCTION ARGUMENT, so
overrideAttrs cannot reach it — it needs `.override`, applied before
`.overrideAttrs` so the latter is not applied to the derivation being replaced.

The assertion did its job: it caught a compositor that would have installed
under our name and then denied every nested game an HDR10 swapchain, which is
the one outcome the header calls the worst. But it only fires after a full
build (MEASURED: run 19323), which is an expensive way to learn a default.

enricobuehler merged commit bd140bd232 into main

2026-08-19 12:51:40 +00:00

enricobuehler deleted branch gamescope-enable-wsi-layer

2026-08-19 12:51:41 +00:00

enricobuehler referenced this issue from a commit

2026-08-19 13:39:10 +00:00

fix(nix): make $out writable before the prune — reshade installs read-only

enricobuehler referenced this pull request

2026-08-19 14:07:48 +00:00

The gamescope prune can't delete reshade — it installs under read-only directories #336

enricobuehler referenced this issue from a commit

2026-08-19 23:24:27 +00:00