[GH-ISSUE #222 ] FR: HDR support #149

Author

Owner

@Hukuma1 commented on GitHub (Jul 5, 2025):

Oh oops! I feel silly copy-pastaing all that now haha. Keep up the great work! I'll leave this open as a feature request?

@Hukuma1 commented on GitHub (Jul 5, 2025): Oh oops! I feel silly copy-pastaing all that now haha. Keep up the great work! I'll leave this open as a feature request?

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Jul 5, 2025):

Sure thing! To be fair it wasn't written anywhere else!

@ABeltramo commented on GitHub (Jul 5, 2025): Sure thing! To be fair it wasn't written anywhere else!

bsakaguchi commented

Author

Owner

@RyuunosukeDS3 commented on GitHub (Nov 17, 2025):

Hey! Just curious to know if anything changed since the last update on this. Are we getting close to HDR or there is still a lot to figure out?

@RyuunosukeDS3 commented on GitHub (Nov 17, 2025): Hey! Just curious to know if anything changed since the last update on this. Are we getting close to HDR or there is still a lot to figure out?

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Nov 17, 2025):

Unfortunately it seems that Smithay doesn't have support for it https://github.com/Smithay/smithay/pull/1143

Having proper HDR in our custom Wayland compositor is probably the first step required. After that we can start building out the additional video encoding pipelines and see what actually supports HDR downstream in our clients (Sway, Gamescope all the way down to Steam and so on..)

@ABeltramo commented on GitHub (Nov 17, 2025): Unfortunately it seems that Smithay doesn't have support for it https://github.com/Smithay/smithay/pull/1143 Having proper HDR in our custom Wayland compositor is probably the first step required. After that we can start building out the additional video encoding pipelines and see what actually supports HDR downstream in our clients (Sway, Gamescope all the way down to Steam and so on..)

bsakaguchi commented

Author

Owner

@macher91 commented on GitHub (Dec 23, 2025):

Actually, Smithay does have HDR support. It supports the color-management-v1 Wayland protocol (which was standardized recently) and provides the necessary backend support for HDR metadata and WCG (Wide Color Gamut) through DRM/KMS. It's already being utilized by projects like COSMIC

@macher91 commented on GitHub (Dec 23, 2025): Actually, Smithay does have HDR support. It supports the color-management-v1 Wayland protocol (which was standardized recently) and provides the necessary backend support for HDR metadata and WCG (Wide Color Gamut) through DRM/KMS. It's already being utilized by projects like COSMIC

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Dec 23, 2025):

Actually, Smithay does have HDR support. It supports the color-management-v1 Wayland protocol

@macher91 are you sure about that, and can you provide any reference?
The official list of implemented wayland protocols links to https://github.com/Smithay/smithay/pull/1143 for color-management-v1. I can't find an official source for Cosmic but the Arch Wiki only says that

The COSMIC developers have promised HDR support in the initial stable release.

Only other thing I could find is https://github.com/pop-os/cosmic-comp/issues/1384 which seems to confirm that there's no HDR support in COSMIC.

I suppose only @Drakulix can say for sure, but from a quick look around I don't see HDR implemented..

@ABeltramo commented on GitHub (Dec 23, 2025): > Actually, Smithay does have HDR support. It supports the color-management-v1 Wayland protocol @macher91 are you sure about that, and can you provide any reference? The official list of [implemented wayland protocols](https://github.com/Smithay/smithay/issues/781) links to https://github.com/Smithay/smithay/pull/1143 for `color-management-v1`. I can't find an official source for Cosmic but the [Arch Wiki](https://wiki.archlinux.org/title/HDR_monitor_support#COSMIC) only says that > The [COSMIC](https://wiki.archlinux.org/title/COSMIC) developers have [promised HDR support](https://blog.system76.com/post/may-flowers-spring-cosmic-showers) in the initial stable release. Only other thing I could find is https://github.com/pop-os/cosmic-comp/issues/1384 which seems to confirm that there's no HDR support in COSMIC. I suppose only @Drakulix can say for sure, but from a quick look around I don't see HDR implemented..

bsakaguchi commented

Author

Owner

@Drakulix commented on GitHub (Dec 23, 2025):

Actually, Smithay does have HDR support. It supports the color-management-v1 Wayland protocol

@macher91 are you sure about that, and can you provide any reference? The official list of implemented wayland protocols links to Smithay/smithay#1143 for color-management-v1. I can't find an official source for Cosmic but the Arch Wiki only says that

The COSMIC developers have promised HDR support in the initial stable release.

Only other thing I could find is pop-os/cosmic-comp#1384 which seems to confirm that there's no HDR support in COSMIC.

I suppose only @Drakulix can say for sure, but from a quick look around I don't see HDR implemented..

The PR you linked is the only work on smithay related to HDR support in the moment. COSMIC also indeed doesn't have any HDR support atm.

For fullscreen clients you can get away with hacking something together, but as soon as you potentially have multiple windows to render it falls apart as you might need to convert between color spaces and blend correctly.

I am finally looking into working on this in the new year, but it might still take a bit until wolf can adopt new smithay code with minimal changes. If you want to hack something together for gamescope or sway in the meantime, I am happy to provide some pointers.

@Drakulix commented on GitHub (Dec 23, 2025): > > Actually, Smithay does have HDR support. It supports the color-management-v1 Wayland protocol > > [@macher91](https://github.com/macher91) are you sure about that, and can you provide any reference? The official list of [implemented wayland protocols](https://github.com/Smithay/smithay/issues/781) links to [Smithay/smithay#1143](https://github.com/Smithay/smithay/pull/1143) for `color-management-v1`. I can't find an official source for Cosmic but the [Arch Wiki](https://wiki.archlinux.org/title/HDR_monitor_support#COSMIC) only says that > > > The [COSMIC](https://wiki.archlinux.org/title/COSMIC) developers have [promised HDR support](https://blog.system76.com/post/may-flowers-spring-cosmic-showers) in the initial stable release. > > Only other thing I could find is [pop-os/cosmic-comp#1384](https://github.com/pop-os/cosmic-comp/issues/1384) which seems to confirm that there's no HDR support in COSMIC. > > I suppose only [@Drakulix](https://github.com/Drakulix) can say for sure, but from a quick look around I don't see HDR implemented.. The PR you linked is the only work on smithay related to HDR support in the moment. COSMIC also indeed doesn't have any HDR support atm. For fullscreen clients you can get away with hacking something together, but as soon as you potentially have multiple windows to render it falls apart as you might need to convert between color spaces and blend correctly. I am finally looking into working on this in the new year, but it might still take a bit until wolf can adopt new smithay code with minimal changes. If you want to hack something together for gamescope or sway in the meantime, I am happy to provide some pointers.

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Dec 23, 2025):

Thanks @Drakulix for the quick reply!

If you want to hack something together for gamescope or sway in the meantime, I am happy to provide some pointers.

That would definitely be interesting since a single fullscreen app is always going the be the main usecase for Wolf (and gst-wayland-comp by extension). If you can spare some pointers I'll look into it after the xmass holidays, I'm sure also @DatCaptainHorse would be interested 😉

@ABeltramo commented on GitHub (Dec 23, 2025): Thanks @Drakulix for the quick reply! > If you want to hack something together for gamescope or sway in the meantime, I am happy to provide some pointers. That would definitely be interesting since a single fullscreen app is always going the be the main usecase for Wolf (and gst-wayland-comp by extension). If you can spare some pointers I'll look into it after the xmass holidays, I'm sure also @DatCaptainHorse would be interested 😉

bsakaguchi commented

Author

Owner

@Drakulix commented on GitHub (Dec 23, 2025):

That would definitely be interesting since a single fullscreen app is always going the be the main usecase for Wolf (and gst-wayland-comp by extension). If you can spare some pointers I'll look into it after the xmass holidays, I'm sure also @DatCaptainHorse would be interested 😉

Okay sure.

You still need the color-management-v1 protocol, as gamescope (or nested sway, if it supports that) would use this protocol to send you HDR metadata. So you either want to rebase https://github.com/Smithay/smithay/pull/1143 and use a smithay-fork or extract the contents into gst-wayland-comp (the code should work fine out of tree, but some imports, etc need to be cleaned up).

This only gives you data from the client, it obviously doesn't change any rendering. You probably want to support as little in terms of what the protocol offers as possible. For gamescope/gaming the following stuff should be sufficient:

perceptual rendering intent (and just ignore it, this basically means "the compositor does what it wants")
features: parametric
transfer functions: gamma22, st2084_pq
primaries: srgb, bt2020

With that srgb + gamma22 is basically what you are currently doing, while HDR apps should use BT2020 + PQ.

I don't think gamescope uses ext_srgb or hgl, but possibly check the source. It could probably make use of luminances, extended-color-volume and more, but I think it doesn't need it and can composite with just these. Using something like wine-wayland directly would probably need Windows-scrgb and much more. Also this is most likely not enough for video-players, but one step at a time.

I think you also need wp-color-representation-v1, but only for the alpha-modes. And premultiplied vs straight alpha is easy to support in the shader.

This then means you will not only get windows in the sRGB color space, but also BT2020.

And for BT2020 you don't need to modify these values at all, if you are not rendering multiple windows, you just need to make sure the framebuffer has enough bits to represent the high color fidelity. Which is probably already has. You want to make sure you use at least a 10-bit format. (Something like ARGB2101010 is sufficient and in most cases pretty efficient. ARGB16161616f (16-bit float per component) works as well, but is probably more resource intensive.

Select something based on what your gst-pipeline supports, you need to make sure you never drop down to 8-bit buffers. If you can only encode 8-bit buffers, don't advertise the protocol.

Now Steam and other apps won't magically output HDR contents and I am not sure gamescope will internally convert everything to BT2020 or send you sRGB image descriptions while no HDR game is running. It might work to simply not advertise sRGB+gamma22, but a lot of apps will likely complain. So you need a new shader, that renders sRGB content in BT2020 color space. You can probably find something simple online to do that.

And that's basically it. Now you just need to set the color space on the pipeline, so that gstreamer will do the right thing and pass HDR-enabled to the moonlight client. This is the most basic implementation, but it should work.
Afterwards there are a lot of possible optimizations. Moonlight likely sends you information about the HDR properties of the display, e.g. it's maximum brightness, etc. Content out of that range will potentially get clipped, etc.

You can take this data and send it back using the protocol and allow the client to give you more data by enabling more features. You then need to figure out, if you can simply encode these bits on the gst-pipeline or if that means you might need to touch the buffer after all and mess with the color values.

But you can figure that out once it works at all, though until then it might not look the best depending on the display.

@Drakulix commented on GitHub (Dec 23, 2025): > That would definitely be interesting since a single fullscreen app is always going the be the main usecase for Wolf (and gst-wayland-comp by extension). If you can spare some pointers I'll look into it after the xmass holidays, I'm sure also [@DatCaptainHorse](https://github.com/DatCaptainHorse) would be interested 😉 Okay sure. 1. You still need the color-management-v1 protocol, as gamescope (or nested sway, if it supports that) would use this protocol to send you HDR metadata. So you either want to rebase https://github.com/Smithay/smithay/pull/1143 and use a smithay-fork or extract the contents into `gst-wayland-comp` (the code should work fine out of tree, but some imports, etc need to be cleaned up). This only gives you data from the client, it obviously doesn't change any rendering. You probably want to support as little in terms of what the protocol offers as possible. For gamescope/gaming the following stuff should be sufficient: - perceptual rendering intent (and just ignore it, this basically means "the compositor does what it wants") - features: parametric - transfer functions: gamma22, st2084_pq - primaries: srgb, bt2020 With that srgb + gamma22 is basically what you are currently doing, while HDR apps should use BT2020 + PQ. I don't think gamescope uses ext_srgb or hgl, but possibly check the source. It could probably make use of luminances, extended-color-volume and more, but I think it doesn't need it and can composite with just these. Using something like wine-wayland directly would probably need Windows-scrgb and much more. Also this is most likely not enough for video-players, but one step at a time. I think you also need wp-color-representation-v1, but only for the alpha-modes. And premultiplied vs straight alpha is easy to support in the shader. 2. This then means you will not only get windows in the sRGB color space, but also BT2020. And for BT2020 you don't need to modify these values at all, if you are not rendering multiple windows, you just need to make sure the framebuffer has enough bits to represent the high color fidelity. Which is probably already has. You want to make sure you use at least a 10-bit format. (Something like ARGB2101010 is sufficient and in most cases pretty efficient. ARGB16161616f (16-bit float per component) works as well, but is probably more resource intensive. Select something based on what your gst-pipeline supports, you need to make sure you never drop down to 8-bit buffers. If you can only encode 8-bit buffers, don't advertise the protocol. Now Steam and other apps won't magically output HDR contents and I am not sure gamescope will internally convert everything to BT2020 or send you sRGB image descriptions while no HDR game is running. It might work to simply not advertise sRGB+gamma22, but a lot of apps will likely complain. So you need a new shader, that renders sRGB content in BT2020 color space. You can probably find something simple online to do that. 3. And that's basically it. Now you just need to set the color space on the pipeline, so that gstreamer will do the right thing and pass HDR-enabled to the moonlight client. This is the most basic implementation, but it should work. 4. Afterwards there are a lot of possible optimizations. Moonlight likely sends you information about the HDR properties of the display, e.g. it's maximum brightness, etc. Content out of that range will potentially get clipped, etc. You can take this data and send it back using the protocol and allow the client to give you more data by enabling more features. You then need to figure out, if you can simply encode these bits on the gst-pipeline or if that means you might need to touch the buffer after all and mess with the color values. But you can figure that out once it works at all, though until then it might not look the best depending on the display.

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Dec 23, 2025):

Thanks for the very detailed answer! I'll try hacking something when I'm back home!

@ABeltramo commented on GitHub (Dec 23, 2025): Thanks for the very detailed answer! I'll try hacking something when I'm back home!

bsakaguchi commented

Author

Owner

@DatCaptainHorse commented on GitHub (Dec 23, 2025):

That would definitely be interesting since a single fullscreen app is always going the be the main usecase for Wolf (and gst-wayland-comp by extension). If you can spare some pointers I'll look into it after the xmass holidays, I'm sure also @DatCaptainHorse would be interested 😉

🐴 - yep, though my monitor supports only "fake HDR" (HDR 400 nits), it might be useful for testing early implementations if you go forward with that 🙂

@DatCaptainHorse commented on GitHub (Dec 23, 2025): > That would definitely be interesting since a single fullscreen app is always going the be the main usecase for Wolf (and gst-wayland-comp by extension). If you can spare some pointers I'll look into it after the xmass holidays, I'm sure also [@DatCaptainHorse](https://github.com/DatCaptainHorse) would be interested 😉 🐴 - yep, though my monitor supports only "fake HDR" (HDR 400 nits), it might be useful for testing early implementations if you go forward with that 🙂

bsakaguchi commented

Author

Owner

@realaod commented on GitHub (Jul 23, 2026):

This needs to be a thing in GoW now. When can we expect true HDR support? The latest Nvidia drivers support HDR natively now.

@realaod commented on GitHub (Jul 23, 2026): This needs to be a thing in GoW now. When can we expect true HDR support? The latest Nvidia drivers support HDR natively now.

bsakaguchi commented

Author

Owner

@JBailes commented on GitHub (Jul 23, 2026):

We already have HDR in testing in gst-wayland, and have had in testing for a few weeks.

@JBailes commented on GitHub (Jul 23, 2026): We already have HDR in testing in gst-wayland, and have had in testing for a few weeks.

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Jul 23, 2026):

There are two parts to this:

Being able to encode and stream in HDR
Being able to have a functional HDR Wayland compositor + apps that support that

We are currently working on 1 (https://github.com/games-on-whales/gst-wayland-display/pull/37), and there's been recent upstream interest in 2 (https://github.com/Smithay/smithay/pull/1143) that we'll need to bring in.

When can we expect true HDR support?

No ETA, it'll be there when everything will be implemented; any help is appreciated though 😉

@ABeltramo commented on GitHub (Jul 23, 2026): There are two parts to this: 1. Being able to encode and stream in HDR 2. Being able to have a functional HDR Wayland compositor + apps that support that We are currently working on 1 (https://github.com/games-on-whales/gst-wayland-display/pull/37), and there's been recent upstream interest in 2 (https://github.com/Smithay/smithay/pull/1143) that we'll need to bring in. > When can we expect true HDR support? No ETA, it'll be there when everything will be implemented; any help is appreciated though 😉

bsakaguchi commented