SUMMARY The latest compiled git version of KDE Plasma that I've tested, completely misinterprets an HDR Display's Color Format, regarding HDR content when using `dmabuf-wayland`. STEPS TO REPRODUCE 1. Obtain and build the latest git version of KDE Plasma 2. Play any HDR videos (For this case, MPV was used, But this issue persists in Firefox and Gamescope as well) 3. Check the Display Information (Pressing `i` in MPV allows this information to be viewed) OBSERVED RESULT In MPV, The format is shown as `P010` regardless of what HDR monitor is used. This doesn't reflect said HDR display's color format and thus results in washed out colors. EXPECTED RESULT For the HDR Display I've tested, the color format should be reported as `RGB10A2` (Test with the latest release version of Plasma `6.3.4` and `VK_hdr_layer`) SOFTWARE/OS VERSIONS Linux/KDE Plasma: `6.14.3-zen1-1-zen`, KDE Plasma `6.4-dev` KDE Plasma Version: `6.3.80-g3f7aefed00` KDE Frameworks Version: `6.14.0-gb445048` Qt Version: `6.9.0` ADDITIONAL INFORMATION A Temporary fix to this issue would be to use `VK_hdr_layer` instead.
You only get some 10bpc RGB format when P010 isn't supported and the video player has to do additional (inefficient) conversions. P010 is what video players are supposed to use. When you say the video is "washed out", what exactly do you mean?
(In reply to Zamundaaa from comment #1) > You only get some 10bpc RGB format when P010 isn't supported and the video > player has to do additional (inefficient) conversions. P010 is what video > players are supposed to use. > > When you say the video is "washed out", what exactly do you mean? Colors appear less vibrant than they should be and dark areas in a video appear brighter than expected.
This is the output I get from MPV in KDE Plasma 6.3.4 ``` ● Video --vid=1 (av1 3840x2160 30 fps) [default] ● Audio --aid=1 (aac 2ch 44100 Hz) [default] [autoconvert] HW-uploading to vaapi [autoconvert] Converting yuv420p10 -> rgb30 [hwupload] upload rgb30 -> vaapi[rgb30] AO: [pipewire] 44100Hz stereo 2ch floatp VO: [dmabuf-wayland] 3840x2160 vaapi[rgb30] ``` And this is the output from 6.3.80-g3f7aefed00 ``` ● Video --vid=1 (av1 3840x2160 30 fps) [default] ● Audio --aid=1 (aac 2ch 44100 Hz) [default] [autoconvert] HW-uploading to vaapi [autoconvert] Converting yuv420p10 -> p010 [hwupload] upload p010 -> vaapi[p010] AO: [pipewire] 44100Hz stereo 2ch floatp VO: [dmabuf-wayland] 3840x2160 vaapi[p010] ```
That looks correct. Maybe you're noticing the difference between bt.2020 vs. bt.709 yuv coefficients, then this would be fixed with https://invent.kde.org/plasma/kwin/-/merge_requests/7209 + https://github.com/mpv-player/mpv/pull/14936 I personally don't see a difference between > mpv --vo=gpu-next --gpu-api=vulkan --gpu-context=waylandvk --target-colorspace-hint "Samsung Travel With My Pet HDR UHD 4K Demo.ts" and > mpv --vo=dmabuf-wayland "Samsung Travel With My Pet HDR UHD 4K Demo.ts" as well as dmabuf-wayland with the bt709 coefficients forced though... What video are you testing this with? Also, please play an HDR video in mpv, press "i", and upload a screenshot of that here, maybe some difference is visible in that data.
Created attachment 180465 [details] MPV information The image on the top is MPV running inside KDE Plasma 6.3.8 The image below shows MPV running on KDE Plasma 6.3.80-g3f7aefed00
`mpv` with the color representation mr outputs this: ``` ● Video --vid=1 (av1 3840x2160 59.9401 fps) [default] ● Audio --aid=1 --alang=eng (aac 6ch 48000 Hz) [default] [autoconvert] HW-uploading to vaapi [autoconvert] Converting yuv420p10 -> p010 [hwupload] upload p010 -> vaapi[p010] AO: [pipewire] 48000Hz 5.1 6ch floatp VO: [dmabuf-wayland] 3840x2160 vaapi[p010] wp_color_representation_surface_v1#38: error 3: The buffer has a YCbCr format, but color representation is identity! ``` Any ideas?
Ok so I did a little bit more research and tested out other configurations and managed to reach this conclusion: 1) conversion P010 is intentional in kwin git. However, it does suffer from the aforementioned issues (dark areas appearing brighter and having a gray tint as well as colors not being as vibrant as RGB30) 2) I couldn't replicate the same issue on mutter git. Thus this confirms that this is an issue with kwin instead. Content displayed through P010 and RGB30 look identical on mutter git. 3) A similar issue was reported here: https://github.com/mpv-player/mpv/issues/16069. 4) A temporary workaround would be to append `vf=format=rgb30` in mpv. However, I couldn't find a workaround for Firefox regarding this issue. 5) This issue doesn't occur in "some" HDR content. The majority of the content that seem to have this issue are obtained from YouTube (e.g: https://www.youtube.com/watch?v=GdNjjhJUibU, https://www.youtube.com/watch?v=njX2bu-_Vw4)
Created attachment 180471 [details] fix the mpv mr
(In reply to WeathrdKde from comment #6) > `mpv` with the color representation mr outputs this: > ``` > ● Video --vid=1 (av1 3840x2160 59.9401 fps) [default] > ● Audio --aid=1 --alang=eng (aac 6ch 48000 Hz) [default] > [autoconvert] HW-uploading to vaapi > [autoconvert] Converting yuv420p10 -> p010 > [hwupload] upload p010 -> vaapi[p010] > AO: [pipewire] 48000Hz 5.1 6ch floatp > VO: [dmabuf-wayland] 3840x2160 vaapi[p010] > wp_color_representation_surface_v1#38: error 3: The buffer has a YCbCr > format, but color representation is identity! > ``` > Any ideas? It's a bug in the mpv MR, you can use that patch to fix it. (In reply to WeathrdKde from comment #7) > 3) A similar issue was reported here: > https://github.com/mpv-player/mpv/issues/16069. That's a different problem, and not specific to KWin (and one that I can't replicate either). > 4) A temporary workaround would be to append `vf=format=rgb30` in mpv. > However, I couldn't find a workaround for Firefox regarding this issue. > 5) This issue doesn't occur in "some" HDR content. The majority of the > content that seem to have this issue are obtained from YouTube (e.g: > https://www.youtube.com/watch?v=GdNjjhJUibU, > https://www.youtube.com/watch?v=njX2bu-_Vw4) Ok, I'll test those when I have a better internet connection
(In reply to Zamundaaa from comment #8) > Created attachment 180471 [details] > fix the mpv mr Fixes the crash, and I can confirm that wp_color_representation_manager_v1is being used. However, this still doesn't fix the core issue.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7544
(In reply to Bug Janitor Service from comment #11) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/kwin/-/merge_requests/7544 This MR does indeed resolve this issue. Both Firefox and MPV now display HDR content formatted through P010 correctly.
(In reply to WeathrdKde from comment #12) > (In reply to Bug Janitor Service from comment #11) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/kwin/-/merge_requests/7544 > > This MR does indeed resolve this issue. Both Firefox and MPV now display HDR > content formatted through P010 correctly. On second examination, colors are still off. Only the issue with dark areas appearing brighter than expected are resolved.
Git commit e6fbc8a0a254ca9276e757dd1962a99a6910d4b3 by Xaver Hugl. Committed on 22/04/2025 at 09:16. Pushed by zamundaaa into branch 'master'. wayland/surface: pass encoding range to the color descriptiion too Otherwise it just gets completely ignored, and you end up with limited range video being interpreted as full range. M +2 -1 src/core/colorspace.cpp M +1 -1 src/core/colorspace.h M +1 -1 src/wayland/surface.cpp https://invent.kde.org/plasma/kwin/-/commit/e6fbc8a0a254ca9276e757dd1962a99a6910d4b3
(In reply to WeathrdKde from comment #13) > On second examination, colors are still off. Only the issue with dark areas > appearing brighter than expected are resolved. Is that with the color representation MR? Without it, the colors are expected to be slightly wrong (which mpv and Firefox would have to prevent, if they care about it enough to sacrifice efficiency for it)
(In reply to Zamundaaa from comment #15) > (In reply to WeathrdKde from comment #13) > > On second examination, colors are still off. Only the issue with dark areas > > appearing brighter than expected are resolved. > Is that with the color representation MR? Without it, the colors are > expected to be slightly wrong (which mpv and Firefox would have to prevent, > if they care about it enough to sacrifice efficiency for it) Yes, That is with the color representation MR. Both in kwin and mpv.
Created attachment 180518 [details] P010 MPV with Color Representation MR and MR 7544 The most glaring example I found was in this scene where there’s an obvious banding issue and colors are slightly off. This is not observed in RGB30z
I can see some difference, but I don't know where it would come from. Our ycbcr->rgb conversion seems to match libplacebo's calculations exactly.
(In reply to Zamundaaa from comment #9) > (In reply to WeathrdKde from comment #6) > > `mpv` with the color representation mr outputs this: > > ``` > > ● Video --vid=1 (av1 3840x2160 59.9401 fps) [default] > > ● Audio --aid=1 --alang=eng (aac 6ch 48000 Hz) [default] > > [autoconvert] HW-uploading to vaapi > > [autoconvert] Converting yuv420p10 -> p010 > > [hwupload] upload p010 -> vaapi[p010] > > AO: [pipewire] 48000Hz 5.1 6ch floatp > > VO: [dmabuf-wayland] 3840x2160 vaapi[p010] > > wp_color_representation_surface_v1#38: error 3: The buffer has a YCbCr > > format, but color representation is identity! > > ``` > > Any ideas? > It's a bug in the mpv MR, you can use that patch to fix it. can you make a pr (or issue) to mpv?