I’m working on the HDR pipeline for xlibre (https://xlibre.net), which is a DE‑agnostic KMS/DCN‑driven display stack used in the Sonic Desktop project (https://github.com/Sonic-DE). We’ve been testing this work on OpenMandriva with systemd running directly on Steam Deck hardware, and we’ve been able to reproduce and fix several HDR and cursor‑plane issues that currently affect Gamescope, Xwayland, and Plasma on the Deck OLED.
I’m opening this because vkroots looks like the perfect foundation for a Vulkan‑side HDR metadata passthrough layer, and I’d like to collaborate or at least validate the approach with you. This is our prototype for mpv that we have working so far https://github.com/cepelinas9000/VK_xlibre_layer
Steam Deck OLED’s HDR capabilities are currently limited by compositor‑centric HDR implementations in KDE/GNOME and by Xwayland cursor‑plane regressions. Valve’s own PRs for cursor visibility were rejected upstream, but the fixes are already merged into xlibre. The invisible cursor issue tracked here is a good example:
ValveSoftware/steam-for-linux#8604
We’ve confirmed that the Deck OLED panel behaves correctly when metadata is passed directly to KMS/DCN without compositor tone‑mapping or protocol‑level HDR abstractions.
I’m prototyping a vkroots‑based Vulkan layer that:
- intercepts HDR metadata from Vulkan swapchains
- extracts DXGI‑equivalent values (MaxCLL, MaxFALL, mastering primaries, luminance)
- passes them directly to xlibre’s KMS/DCN HDR path
- enables mixed SDR/HDR windows without compositor involvement
- avoids the static‑HDR limitations of current Wayland protocols
This mirrors how Windows and consoles handle HDR, and it aligns with the Deck OLED’s hardware path.
vkroots provides exactly the kind of lightweight interception layer needed for this. It’s faster and cleaner than the custom interception code we were using before, and it would let us prototype HDR metadata passthrough in a way that’s easy to maintain and upstream.
What I’d like from you if possible:
- validation that this approach makes sense
- any guidance on swapchain interception pitfalls
- whether you see conflicts with Gamescope’s long‑term HDR plans
- whether you’d be open to a PR once the prototype is stable
This work could help unblock real HDR gaming on Linux outside of compositor‑centric designs, and it may be useful for Steam Deck OLED users who currently get washed‑out static HDR due to Wayland compositor tone‑mapping.
If this direction aligns with vkroots’ goals, I’d be happy to share code as soon as the prototype is ready.
Thanks for your time and for all your work on DXVK, vkd3d‑proton, and the Deck graphics stack.
— Collin
I’m working on the HDR pipeline for xlibre (https://xlibre.net), which is a DE‑agnostic KMS/DCN‑driven display stack used in the Sonic Desktop project (https://github.com/Sonic-DE). We’ve been testing this work on OpenMandriva with systemd running directly on Steam Deck hardware, and we’ve been able to reproduce and fix several HDR and cursor‑plane issues that currently affect Gamescope, Xwayland, and Plasma on the Deck OLED.
I’m opening this because vkroots looks like the perfect foundation for a Vulkan‑side HDR metadata passthrough layer, and I’d like to collaborate or at least validate the approach with you. This is our prototype for mpv that we have working so far https://github.com/cepelinas9000/VK_xlibre_layer
Steam Deck OLED’s HDR capabilities are currently limited by compositor‑centric HDR implementations in KDE/GNOME and by Xwayland cursor‑plane regressions. Valve’s own PRs for cursor visibility were rejected upstream, but the fixes are already merged into xlibre. The invisible cursor issue tracked here is a good example:
ValveSoftware/steam-for-linux#8604
We’ve confirmed that the Deck OLED panel behaves correctly when metadata is passed directly to KMS/DCN without compositor tone‑mapping or protocol‑level HDR abstractions.
I’m prototyping a vkroots‑based Vulkan layer that:
This mirrors how Windows and consoles handle HDR, and it aligns with the Deck OLED’s hardware path.
vkroots provides exactly the kind of lightweight interception layer needed for this. It’s faster and cleaner than the custom interception code we were using before, and it would let us prototype HDR metadata passthrough in a way that’s easy to maintain and upstream.
What I’d like from you if possible:
This work could help unblock real HDR gaming on Linux outside of compositor‑centric designs, and it may be useful for Steam Deck OLED users who currently get washed‑out static HDR due to Wayland compositor tone‑mapping.
If this direction aligns with vkroots’ goals, I’d be happy to share code as soon as the prototype is ready.
Thanks for your time and for all your work on DXVK, vkd3d‑proton, and the Deck graphics stack.
— Collin