1642854 - (hdr-video-linux) HDR video support for Linux

Status: NEW

(Core :: Audio/Video: Playback, enhancement)

Description

[romulasry]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Go to https://www.youtube.com/channel/UCve7_yAZHFNipzeAGBI5t9g/ and view a video on Linux.

Actual results:

VIdeos were in SDR

Expected results:

Been in HDR

Comment 1

[romulasry]

(In reply to romulasry from comment #0)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Go to https://www.youtube.com/channel/UCve7_yAZHFNipzeAGBI5t9g/ and view a video on Linux.

Actual results:

VIdeos were in SDR

Expected results:

Been in HDR

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Elle Solomina (she/her)]

Hey! It's still not working properly in Firefox 79 Oo Rly??? It's not a platform issue, on Windows and Linux, and Android is absolutely same, Firefox not working with HDR.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

To have a roadmap here let's point out some tasks we need to finish to have HDR support on Linux:

• Extend existing NativeLayerWayland() to support external images (that's how video frames are injected to renderer). MacOS variant is here: https://phabricator.services.mozilla.com/D84638
• Extend DMABufSurfaces to hold HDR YUV surfaces (10-bit formats)
• Extend DMABufSurfaces to hold HDR color data
• Pass HDR data from FFmpeg decoder via DMABufSurfaces to MozContainer (or something else) and apply them during wl_surface_commit
• Propagate Linux/HDR support so web playes can serve us HDR content (i.e. clips in bt.2020 color space with yuv420p10 bit planes)
• Optionally update NativeLayerRootWayland to do local composition (by GL?) and send to Wayland compositor as less subsurfaces as possible.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Attachment: hdr-wip-2.patch

WIP v.2 patch, mostly contains unification for layer and multi buffer code.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1642854 [Wayland] hdr patch

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Attachment: WIP: Bug 1642854 [WIP][Wayland] hdr patch v.14 - viewport scale

Comment 8

[Martin Stránský [:stransky] (ni? me)]

A new patch which uses viewport scale instead of buffer scale. It should fix all the "wrong buffer size" bugs when Firefox is moved between screens with different scales. We can also remove all the stuff we use to stop compositor rendering during scale changes at nsWindow.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1642854 [WIP][Wayland] hdr patch v.16

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Attachment: WIP: Bug 1642854 [WIP][Wayland] hdr patch v.23

Comment 11

[Martin Stránský [:stransky] (ni? me)]

The patch here implements very experimental HDR playback. As it's missing correct wl_buffer format negotiation (Bug 1743631) and trows whatever it has to compositor it tends to crash due to unsupported modifiers. It needs further work on stabilization, layers rendering optimization and some layers fixes (D&D is broken due to missing layer screenshotter and there are rendering errors on scrolling).

Comment 12

[s.zharkoff]

I have tried 135beta1, 135beta2, trunk from yesterday morning - where fixes for wayland surfaces applied.

Everywhere notice a power consumption regression on idle. Same pages opened in 134 consumes 5 watts average on idle, 135 and trunk - 8 watts.
When playing videos on youtube the difference is not so big but still seems to be there - around 10 watts 134 and 11-12 135 and higher.

The FF processes in 135 and 134 seems to consume about the same CPU but with 135 version and higher compositor always runs at 10-13% CPU even when nothing is happening in FF. With 134 version at the same condition compositor is somewhere at the end of process list using abut 1%.

I understand that this is a very early WIP stage and such things is normal at this moment, just want to make early warning that there is something wrong in new wayland code related to the idle CPU/battery usage.

Use wayfire compositor based on wlroots 18.2.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

(In reply to s.zharkoff from comment #12)

I have tried 135beta1, 135beta2, trunk from yesterday morning - where fixes for wayland surfaces applied.

Everywhere notice a power consumption regression on idle. Same pages opened in 134 consumes 5 watts average on idle, 135 and trunk - 8 watts.
When playing videos on youtube the difference is not so big but still seems to be there - around 10 watts 134 and 11-12 135 and higher.

The FF processes in 135 and 134 seems to consume about the same CPU but with 135 version and higher compositor always runs at 10-13% CPU even when nothing is happening in FF. With 134 version at the same condition compositor is somewhere at the end of process list using abut 1%.

I understand that this is a very early WIP stage and such things is normal at this moment, just want to make early warning that there is something wrong in new wayland code related to the idle CPU/battery usage.

Use wayfire compositor based on wlroots 18.2.

Do you mean with the WIP: Bug 1642854 [WIP][Wayland] hdr patch v.19 patch applied or without it?
Thanks.

Comment 14

[s.zharkoff]

Do you mean with the WIP: Bug 1642854 [WIP][Wayland] hdr patch v.19 patch applied or without it?
Thanks.

It was before applying this patch. As I understand this patch will not be in 135 - but 135 is already broken. Is this patch supposed to fix the idle issue?

wlroots is not yet capable of HDR signalling, so I do not expect to get HDR on my display and just view regular SDR videos, so in fact the issue is not because of sdr but because of some changes how ff talks with compositor, and those changes already landed in 135. So I guess my coments are not for thos patch but for the whole big wayland rework being done to allow HDR to happen.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to s.zharkoff from comment #14)

Do you mean with the WIP: Bug 1642854 [WIP][Wayland] hdr patch v.19 patch applied or without it?
Thanks.

It was before applying this patch. As I understand this patch will not be in 135 - but 135 is already broken. Is this patch supposed to fix the idle issue?

wlroots is not yet capable of HDR signalling, so I do not expect to get HDR on my display and just view regular SDR videos, so in fact the issue is not because of sdr but because of some changes how ff talks with compositor, and those changes already landed in 135. So I guess my coments are not for thos patch but for the whole big wayland rework being done to allow HDR to happen.

Okay, please file a new bug for it, I'll look at it. Please attach your about:support there.
Thanks.

Comment 16

[s.zharkoff]

Created the new bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1940924

Comment 17

[Martin Stránský [:stransky] (ni? me)]

With the v.21 patch HDR is supposed to work. It includes dmabuf feedback and direct composition from external dmabuf surfaces (WebGL/VA-API). SW HDR rendering is not supported yet so you need VA-API decode of VP9 Profile 2 to decode P10 formats. It's under gfx.wayland.hdr pref.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

There are still some bugs remaining - D&D doesn't work due to missing snapshotter and there are rendering artifacts like missing tiles during scrolling.

Comment 19

[Amine Hassane]

With the latest patch Firefox crashes for me upon starting a HDR video with this error:
GFX1-]: (kde) Wayland protocol error: zwp_linux_buffer_params_v1#857: error 7: importing the supplied dmabufs failed.

Comment 20

[Jonathan Bennett]

I'm also running into https://bugzilla.mozilla.org/show_bug.cgi?id=1732051 trying to test this. Once vsync is disabled, seeing the same error as Amine. Fedora 41 KDE, on an AMD card.

Comment 21

[Robert Mader [:rmader]]

FTR., for fully correct playback we'll also need to implement the color representation protocol - which is getting ready as well.

It mainly needed to tell the compositor whether to use BT601, BT709 or BT2020 matrix coefficients (and limited or full range) in the YCbCr->RGB conversion. Without that compositors like Mutter and KMS drivers will usually default to BT709 while one wants BT2020 for HDR10. The visual impact is not too bad, but visible once you compare directly next to each other.

See also my MR for Gstreamer as example.

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Hello Robert,
we use xx_color_manager_v4 to set surface colorspace:
https://searchfox.org/mozilla-central/rev/d1fbe983fb7720f0a4aca0e748817af11c1a374e/widget/gtk/WaylandSurface.cpp#1356
isn't that enough?
Thanks.

Comment 23

[Robert Mader [:rmader]]

Only for RGB content like games. For YCbCr/YUV content, which is what we're aiming for here, you additionally need the matrix coefficients and range (and in theory chroma location) as specified in ITU-T Rec. 273 - i.e. for HDR10 you want the PQ curve (XX_COLOR_MANAGER_V4_TRANSFER_FUNCTION_ST2084_PQ) and the BT2020 primaries (XX_COLOR_MANAGER_V4_PRIMARIES_BT2020) from the color protocol in combination with BT2020 coefficients/limited range (WP_COLOR_REPRESENTATION_V1_COEFFICIENTS_BT2020/WP_COLOR_REPRESENTATION_V1_RANGE_LIMITED) from the color representation protocol.

But the color representation protocol won't make it into Gnome 48 anyways (I only added some initial plumbing for the KMS properties here) and the error is not too bad. Once the protocol lands - likely in 49 - it should be an easy addition. I just wanted to give you a heads-up.

Some context:

• Weston implementation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1682

Comment 24

[wiagn233]

Final version of wayland color management protocol has just been merged: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/color-management/color-management-v1.xml?ref_type=heads

Comment 25

[GreyXor]

Hello,
Just tried latest nightly and now it run correctly on sway with gfx.webrender.compositor.force-enabled
but I got crashes after randomly navigation

• https://crash-stats.mozilla.org/report/index/d2ee6e63-0cbf-43bc-ac5e-2ffe60250220
• https://crash-stats.mozilla.org/report/index/5cdc4aa3-2c69-4f77-a853-f478d0250220
• https://crash-stats.mozilla.org/report/index/24f593f3-adc5-4535-a5bf-26a780250220

Should I create new issues for that ?

Comment 26

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #25)

Hello,
Just tried latest nightly and now it run correctly on sway with gfx.webrender.compositor.force-enabled
but I got crashes after randomly navigation

• https://crash-stats.mozilla.org/report/index/d2ee6e63-0cbf-43bc-ac5e-2ffe60250220
• https://crash-stats.mozilla.org/report/index/5cdc4aa3-2c69-4f77-a853-f478d0250220
• https://crash-stats.mozilla.org/report/index/24f593f3-adc5-4535-a5bf-26a780250220

Should I create new issues for that ?

Yes please, you can file as blocking this one.

Comment 27

[wiagn233]

Btw we still have some color management issues even in SDR mode, which really needs paying attention on:
https://bugzilla.mozilla.org/show_bug.cgi?id=1939259
https://bugzilla.mozilla.org/show_bug.cgi?id=1834978

Comment 28

[GreyXor]

Latest build : https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5
Cannot see video anymore

tested https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
I can hear the sound, but the image remains black
with gfx.webrender.compositor.force-enabled

Comment 29

[GreyXor]

There a regression with VRR with compositor.force-enabled VRR is not working anymore.

I'm using vbltest to check the actual real refresh rate of my output.

Doing nothing: 32fps
Open nautilus and doing nothing: 32fps
Moving mouse anywhere: 60fps
Open firefox: 60fps
doing nothing in firefox: 60fps
open firefox (without compositor.fore-enabled): 32fps

If I disable compositor.force-enabled then vrr is working as expected again

Comment 30

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #29)

There a regression with VRR with compositor.force-enabled VRR is not working anymore.

I'm using vbltest to check the actual real refresh rate of my output.

Doing nothing: 32fps
Open nautilus and doing nothing: 32fps
Moving mouse anywhere: 60fps
Open firefox: 60fps
doing nothing in firefox: 60fps
open firefox (without compositor.fore-enabled): 32fps

If I disable compositor.force-enabled then vrr is working as expected again

That's possible, please file a new bug for it.
Thanks.

Comment 31

[GreyXor]

(In reply to GreyXor from comment #28)

Latest build : https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5
Cannot see video anymore

tested https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
I can hear the sound, but the image remains black
with gfx.webrender.compositor.force-enabled

what about this issue :stransky ? Should I open a new issue too ? it's basically videos are not working anymore with compositor on

Comment 32

[Martin Stránský [:stransky] (ni? me)]

(In reply to GreyXor from comment #31)

(In reply to GreyXor from comment #28)

Latest build : https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5
Cannot see video anymore

tested https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
I can hear the sound, but the image remains black
with gfx.webrender.compositor.force-enabled

what about this issue :stransky ? Should I open a new issue too ? it's basically videos are not working anymore with compositor on

Yes, please open a new bug for it.
Thanks.

Comment 33

[Jan Alexander Steffens [:heftig]]

Is this supposed to be working? I've enabled .compositor.force-enabled and .wayland.hdr, and something is happening - the video gets much darker and the overlaid video controls are not rendered correctly (posterization) - but it doesn't actually seem to be HDR. It doesn't get any brighter than the UI and the video is still affected by GNOME's HDR Brightness slider.

I've managed to get an HDR image out of mpv, so HDR seems to be working in general, just not in Firefox.

I've tested with https://www.youtube.com/watch?v=5z43FTxB30A.

Firefox Nightly
GNOME 48
Arch Linux

Comment 34

[Martin Stránský [:stransky] (ni? me)]

(In reply to Jan Alexander Steffens [:heftig] from comment #33)

Is this supposed to be working? I've enabled .compositor.force-enabled and .wayland.hdr, and something is happening - the video gets much darker and the overlaid video controls are not rendered correctly (posterization) - but it doesn't actually seem to be HDR. It doesn't get any brighter than the UI and the video is still affected by GNOME's HDR Brightness slider.

I've managed to get an HDR image out of mpv, so HDR seems to be working in general, just not in Firefox.

I've tested with https://www.youtube.com/watch?v=5z43FTxB30A.

Firefox Nightly
GNOME 48
Arch Linux

Please file as separated bug. It's still WIP.

Comment 35

[alekseipesorin]

Looks like this broke something else: enabling gfx.wayland.hdr (Firefox 137 release, Arch Linux) results in "unpainted"/uninitialized areas randomly appearing when scrolling, which turns back to normal whenever a UI element updates itself: https://0x0.st/82JG.png

Comment 36

[Martin Stránský [:stransky] (ni? me)]

(In reply to alekseipesorin from comment #35)

Looks like this broke something else: enabling gfx.wayland.hdr (Firefox 137 release, Arch Linux) results in "unpainted"/uninitialized areas randomly appearing when scrolling, which turns back to normal whenever a UI element updates itself: https://0x0.st/82JG.png

Please test latest nightly only.

Comment 37

[wiagn233]

Color representation protocol is ready to get merged, seems we can start supporting it?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183#note_2867502

Comment 38

[Martin Stránský [:stransky] (ni? me)]

(In reply to wiagn233 from comment #37)

Color representation protocol is ready to get merged, seems we can start supporting it?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183#note_2867502

Can you explain what's that and how/why we should use it?
Thanks?

Comment 39

[wiagn233]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #38)

(In reply to wiagn233 from comment #37)

Color representation protocol is ready to get merged, seems we can start supporting it?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183#note_2867502

Can you explain what's that and how/why we should use it?
Thanks?

Robert have talked about this above: https://bugzilla.mozilla.org/show_bug.cgi?id=1642854#c23

Comment 40

[Martin Stránský [:stransky] (ni? me)]

Okay, but is not supported in Gnome yet. Let's wait until it's there.

Comment 41

[s.zharkoff]

tried to build latest source - and with hdr compositor enabled see the issue with scrolling.
Reported it here -
https://bugzilla.mozilla.org/show_bug.cgi?id=1962033

This was happening some time ago, then fixed - now looks like it is back again.

Comment 42

[Anton Valishin]

This happens on fedora 24 kde on firefox built by fedora when gfx.wayland.hdr is enabled
https://www.youtube.com/watch?v=xL4_DLU5TmY

Firefox
Version 138.0.3
Build ID 20250512220248
Distribution ID fedora
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0
OS Linux 6.14.6-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 9 20:11:19 UTC 2025
OS Theme Breeze / Adwaita
Window Protocol wayland

Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13900K
Memory: 94.0 GiB of RAM
Graphics Processor 1: Intel® Graphics

Comment 43

[Anton Valishin]

Attachment: hdr.mp4

Comment 44

[Anton Valishin]

Comment on attachment 9490323 [details]
hdr.mp4

wrong bug, sorrry

Comment 45

[kode54]

This happens on Arch Linux, running their stable builds of Firefox, and continues to happen with the latest stable.

Firefox
Version 141.0
Build ID 20250721102543
Distribution ID archlinux
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0
OS Linux 6.16.0-rc7-2-cachyos-rc #1 SMP PREEMPT_DYNAMIC Wed, 23 Jul 2025 06:39:47 +0000
OS Theme adw-gtk3-dark / adw-gtk3 (The video was captured from Breeze, though)
Window Protocol wayland

Operating System: Arch Linux
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.16.0-rc7-2-cachyos-rc (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7700X
Memory: 64.0 GiB of RAM
Graphics Processor 1: AMD Radeon RX 7700 XT

https://youtu.be/y4cstqYvsQI

The problem does not replicate with Nightly. I have another issue that does occur with Nightly, which I will post in a second comment.

Comment 46

[kode54]

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is that the HDR video on YouTube appears to be completely blown out, compared to a properly configured mpv using gpu-next and Vulkan HDR, which plays it with the correct color grading.

Firefox
Version 143.0a1
Build ID 20250723074135
Distribution ID archlinux
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0
OS Linux 6.16.0-rc7-2-cachyos-rc #1 SMP PREEMPT_DYNAMIC Wed, 23 Jul 2025 06:39:47 +0000
OS Theme adw-gtk3-dark / adw-gtk3
Window Protocol wayland

Operating System: Arch Linux
Gnome mutter version: 48.4-1
Kernel Version: 6.16.0-rc7-2-cachyos-rc (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7700X
Memory: 64.0 GiB of RAM
Graphics Processor 1: AMD Radeon RX 7700 XT

https://youtu.be/pvMdap1yw6M (Taking longer than expected to process, probably because it's an HDR screen capture.)

Comment 47

[kode54]

(In reply to kode54 from comment #45)

This problem does occur on Nightly, only slightly different, especially since it's happening differently in Gnome.

There's another issue with Stable as well. When I enable gfx.wayland.hdr there, SDR videos don't play at all in YouTube. They present as a green frame instead of the actual picture. HDR videos play, and play with the correct color, unlike Nightly.

Comment 48

[kode54]

(In reply to kode54 from comment #46)

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is that the HDR video on YouTube appears to be completely blown out, compared to a properly configured mpv using gpu-next and Vulkan HDR, which plays it with the correct color grading.

Oops, I accidentally recorded my music into that video, so I had to delete it. Uploaded another:

https://youtu.be/Hw2JcsIJ7QU

Comment 49

[Martin Stránský [:stransky] (ni? me)]

(In reply to kode54 from comment #47)

(In reply to kode54 from comment #45)

This problem does occur on Nightly, only slightly different, especially since it's happening differently in Gnome.

There's another issue with Stable as well. When I enable gfx.wayland.hdr there, SDR videos don't play at all in YouTube. They present as a green frame instead of the actual picture. HDR videos play, and play with the correct color, unlike Nightly.

Please file as separated bug.

Comment 50

[Martin Stránský [:stransky] (ni? me)]

(In reply to kode54 from comment #46)

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is

Bug 1731895

Comment 51

[kode54]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #49)

(In reply to kode54 from comment #47)

(In reply to kode54 from comment #45)

This problem does occur on Nightly, only slightly different, especially since it's happening differently in Gnome.

There's another issue with Stable as well. When I enable gfx.wayland.hdr there, SDR videos don't play at all in YouTube. They present as a green frame instead of the actual picture. HDR videos play, and play with the correct color, unlike Nightly.

Please file as separated bug.

Sorry about that. Also, I already found an applicable green frame bug.

Comment 52

[kode54]

Huh, my e(In reply to kode54 from comment #48)

(In reply to kode54 from comment #46)

Different bug:

It appears the window gaps are still occurring on the scaled display, even under Gnome, with Firefox Nightly. The other bug I'm posting here is that the HDR video on YouTube appears to be completely blown out, compared to a properly configured mpv using gpu-next and Vulkan HDR, which plays it with the correct color grading.

Oops, I accidentally recorded my music into that video, so I had to delete it. Uploaded another:

https://youtu.be/Hw2JcsIJ7QU

Huh, my example video plays correctly, but the original video does not. I figured out the differences here.

My video is:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn (default)

His original video that plays with blown out colors is:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt2020nc/bt2020/arib-std-b67), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn (default)

Comment 53

[Jan Alexander Steffens [:heftig]]

Two different transfer functions - smpte2084 is PQ and arib-std-b67 is HLG. AFAIU GNOME does not support HLG, so Firefox would have to choose PQ and convert the video.

Comment 54

[kode54]

(In reply to Jan Alexander Steffens [:heftig] from comment #53)

Two different transfer functions - smpte2084 is PQ and arib-std-b67 is HLG. AFAIU GNOME does not support HLG, so Firefox would have to choose PQ and convert the video.

I added HLG transfer support to wlroots and labwc, but either it didn't work, or Firefox didn't support it.

Does the transfer function need to be reported as the current output buffer format? It should be reported as a possible alternate surface transfer function.

Comment 55

[kode54]

I just checked:

https://github.com/mozilla-firefox/firefox/blob/96666ecb794f59d5bcba4d5d1d3d5464a650b5be/widget/gtk/WaylandSurface.cpp#L1309-L1310

Firefox just sets ST2084_PQ regardless of what transfer function the video expects.

And I also checked, KDE supports gamma22, but not hlg. So I guess win for me that I added both to wlroots as well, only to find out that my test case isn't using either of them.

Comment 56

[kode54]

It would be great if Firefox could use preferred surface image descriptions in the future. Unfortunately, I don't know how well that's supported by compositors that implement the color management v1 protocol. Currently, wlroots doesn't send that message to clients, and kwin is probably the most likely to currently support it.

Oh well, best stick to what's supported for now, until everyone is on board.

Comment 57

[Martin Stránský [:stransky] (ni? me)]

Please file that as separated bugs blocking this one. We discuss the details there then.
Thanks.

Comment 58

[kode54]

I filed a bug as blocking this one, but it doesn't appear to have registered here?

https://bugzilla.mozilla.org/show_bug.cgi?id=1979908

Comment 59

[Marco Roehrs]

Tried to enable gfx.wayland.hdr on my System.. it worked at first.. (played HDR video on YT) but it had random crashes even when not playing a (HDR) Video.

I reported those crashes.. but no idea where those reports go?!

Fedora 42, KDE Plasma 6.5.1, Firefox 144.0.2 (fedora build)

Comment 60

[Marco Roehrs]

If there is anything to test. I'm happy to deliver real life troubleshooting intel :)

Comment 61

[Martin Stránský [:stransky] (ni? me)]

Please test only latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries

Comment 62

[Marco Roehrs]

Fedora 43 (kernel 6.17.7), KDE Plasma 6.5.2, Firefox 147.0a1 (2025-11-16) (64-bit)

i had to activate gfx.wayland.hdr AND gfx.wayland.hdr.force-enabled to make youtube offer HDR.

playback works, no crashes.. BUT: it looks washed out.

I've checked "Enable HDR", 10bits per color and calibrated it in Plasma Display Configuration

if you need more info (logs etc. let me know how to provide them)

Youtube Nerd-Overlay shows Color smptre2084 (PQ) / bt2020

Comment 63

[Marco Roehrs]

(In reply to Marco Roehrs from comment #62)

Fedora 43 (kernel 6.17.7), KDE Plasma 6.5.2, Firefox 147.0a1 (2025-11-16) (64-bit)

i had to activate gfx.wayland.hdr AND gfx.wayland.hdr.force-enabled to make youtube offer HDR.

playback works, no crashes.. BUT: it looks washed out.

I've checked "Enable HDR", 10bits per color and calibrated it in Plasma Display Configuration

if you need more info (logs etc. let me know how to provide them)

Youtube Nerd-Overlay shows Color smptre2084 (PQ) / bt2020

GPU is Intel integrated Arc (185h / meteorlake)
Monitor is PG27UCDM attached over hdmi cable to Laptop, running at 4k, 10bit, 120hz

Comment 64

[Martin Stránský [:stransky] (ni? me)]

(In reply to Marco Roehrs from comment #62)

Fedora 43 (kernel 6.17.7), KDE Plasma 6.5.2, Firefox 147.0a1 (2025-11-16) (64-bit)

i had to activate gfx.wayland.hdr AND gfx.wayland.hdr.force-enabled to make youtube offer HDR.

playback works, no crashes.. BUT: it looks washed out.

I've checked "Enable HDR", 10bits per color and calibrated it in Plasma Display Configuration

if you need more info (logs etc. let me know how to provide them)

Youtube Nerd-Overlay shows Color smptre2084 (PQ) / bt2020

Please file a new bug for it which blocks this one.
Thanks.

Comment 65

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jimm, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 66

[Martin Stránský [:stransky] (ni? me)]

Would be great to get any performance data how the HDR mode affect overall desktop performance - as we move compositing from Firefox to desktop and also do rapid map/unmap of surfaces during scrolling for instance.

Comment 67

[Thibault [:thibaulltt]]

Hi, I reported bug 2012285, which seems to be similar to Marco's problem a few comments above. I hope this can be somehow linked to this bug :)

Comment 68

[wiagn233]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #66)

Would be great to get any performance data how the HDR mode affect overall desktop performance - as we move compositing from Firefox to desktop and also do rapid map/unmap of surfaces during scrolling for instance.

Kernel KMS color pipeline API would land in next kernel version and KDE also needs this PR to fully utilize color pipeline API to do HW MPO offload, so we won't see much performance difference now.

Comment 69

[Jeff Muizelaar [:jrmuizel]]

Martin, out of curiosity, what things do you think are needed to have HDR video enabled by default?

Comment 70

[Martin Stránský [:stransky] (ni? me)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #69)

Martin, out of curiosity, what things do you think are needed to have HDR video enabled by default?

Bug 1731895 is the main blocker here (and then testing).