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

Merged
enricobuehler merged 1 commits from gamescope-enable-wsi-layer into main 2026-08-19 12:51:40 +00:00
1 Commits
Author SHA1 Message Date
enricobuehler 5711fafa38 fix(nix): build gamescope's WSI layer — nixpkgs defaults enableWsi to false
ci / rust-arm64 (pull_request) Successful in 2m10s
ci / bun-nix (pull_request) Successful in 18s
ci / web (pull_request) Successful in 1m56s
ci / docs-site (pull_request) Successful in 2m39s
ci / rust (pull_request) Successful in 9m5s
nix / flake (pull_request) Successful in 14m27s
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.
2026-08-19 11:44:05 +00:00