Color Management & HDR

[sparklescrewdriver]

Describe the feature

There has been no progress on implementing HDR within the X11 protocol, though it could potentially be approached in two ways. One option is to follow Wayland’s lead (in terms of code i.e. copy it and adjust any licensing requirements to make this feasible) and transition to in sort a X11.1 protocol. This path would be simpler and require less effort but could introduce challenges, such as increased dependency on the Wayland project and reduced independence. It’s a discussion that needs to be revisited, it was considered once before, about five years ago. The topic has become more relevant now, as Wayland has HDR support. However, it might be more beneficial to focus on this improvement after the codebase has been cleaned up. There could also be the introduction of a deep color expansion to the colormap sections of the project. To start off with there would need to the development of a check list of the steps to do - initially when Wayland started the process it looked like the following (sharing to give ideas):

• improve sharing of ICC files !240improve sharing of ICC files !240 (merged)
• assign color spaces to the heads before enabling the output
• implement modules (static, colord) to load color spaces
• compositor plumbing to enable/disable color management
• basic ICC vcgt support
• implement the protocol and extend the surface commit state
• lower color space conversions to a 3D LUT using lcms2
• extract linearization LUT from output color spaces
• gl-renderer changes
• gl-renderer tests to make sure we don't break everything
• !344 (merged)
• !287 (merged)
• actually test different buffer types, formats etc
• 3D LUT support for color space conversions
• gamma correct blending
• fp shadow buffer and/or GL_EXT_shader_framebuffer_fetch_non_coherent
• only assign surfaces to planes when the color space matches the output
• shared CRTC clone mode only for heads with the same color space

It should be implemented because

(see above)

What are the alternatives?

No response

Addtional Information

for more context of past discussion within the x11 project -
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1037

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[mSparks43]

https://yedlin.net/DebunkingHDR/index.html

further, we already have colord

[sparklescrewdriver]

The video you linked gives a good overview of colour theory. There is the issue of still not having HDR as shown by video content in HDR and SDR. The following videos provide somewhat of an explanation in difference and due to the same video you can see the difference on Wayland between HDR and SDR (if you have a display that supports HDR):

• HDR video

• SDR video

For this project to a future there needs to be a full implementation of HDR (eventually). Some characteristics of HDR is addressed by colord, but depending on how HDR is implemented color management may need to be revamped. Within television HDR is currently set out in ITU-R BT.2100-3. Further, HDR is better set out in some of the standards i.e. HDR10 & HDR10+. Here are some more related links to HDR implementations and questions about HDR:

• HDR 10+ White Paper

• Frequently Asked Questions on
  High Dynamic Range and Hybrid Log-Gamma by the BBC

There has been issues in how HDR has been marketed, but it's a technology that needs to be implemented. As without being able to with confidence say that this X11 implementation supports HDR. It will result in people going to the alternative which is Wayland.

[mSparks43]

see the difference on Wayland between HDR and SDR

The point of the video is you shouldn't be able to see any difference. waylands hdr implementation is broken.

[sparklescrewdriver]

see the difference on Wayland between HDR and SDR

The point of the video is you shouldn't be able to see any difference. waylands hdr implementation is broken.

Wayland's implementation of HDR isn't broken. Rather, it's a choice by the content creator. Quite frankly, we don't have a say in whether we want to support it there is content made in HDR that we should support. Furthermore, the video you linked was mainly referring to filmmaking, but the HDR display type is more widely used than just for filmmaking.

[metux]

https://yedlin.net/DebunkingHDR/index.html

In case anybody else wondering about the empty page, too: you have toclick into on the big rect to start the presentation video :)

[mSparks43]

see the difference on Wayland between HDR and SDR

The point of the video is you shouldn't be able to see any difference. waylands hdr implementation is broken.

Wayland's implementation of HDR isn't broken. Rather, it's a choice by the content creator. Quite frankly, we don't have a say in whether we want to support it there is content made in HDR that we should support. Furthermore, the video you linked was mainly referring to filmmaking, but the HDR display type is more widely used than just for filmmaking.

Its broken because the colour and brightness should not change, if the color was red in sdr and it shows green in hdr its just broken.

All you should get with hdr is a slightly clearer image in the very dark areas that sdr just maps to black.

[sparklescrewdriver]

Its broken because the colour and brightness should not change, if the color was red in sdr and it shows green in hdr its just broken.

The key point is that while a color's tone can change, it remains fundamentally the same color. Ultimately, content creators working in HDR determine how their material should be viewed. Additionally, SDR content maintains its consistency since HDR processing typically isn't applied to SDR material when properly implemented.

All you should get with hdr is a slightly clearer image in the very dark areas that sdr just maps to black.

That was the intent, but like with any technology it can be used in other ways. Thus, if it doesn't have negative effects - it should be implemented.

[Quackdoc]

"HDR" as a focus point is IMO wrong, HDR support will come with proper colormanagement pipelines, all "HDR" really is, is a marketing term for colorspaces which utilize transfers that can represent 1000nits+

the basic "minimum checklist" for HDR is

• Gamut mapping (gamut expansion in 99% of cases)
• (inverse) Tonemapping SDR -> HDR
• Getting metadata from applications (having vulkan wsi support is necessary for good support for games and such, could be a layer but hopefully mesa wont be actively hostile to XLibre)
• being able to set the transfer/colorspace being sent to the display

Things like HDR10/HDR10+/Dolby vision can IMO come afterwards.

The common transfers in question are PQ and HLG. scRGB is common in games, Displays typically don't support this it gets mapped to PQ or HLG. HLG is probably the easiest to start with, but has the worst display support, so PQ is probably the better one to start with.

[mSparks43]

One thing I would suggest is that an X11 extension to add vulkan layers to windows would:

1. have a lot of other use cases
2. Allow native functionality similar to valve coded up with gamescope.
3. be a good use case for xnamespace

[metux]

Can you clarify what the exact semantics of these vulkan layers would be here ?

I'm thinking about a network transparent vulkan extension, btw.

[metux]

One thing I would suggest is that an X11 extension to add vulkan layers to windows would:

Any suggestion how it would look like ?

Actually, I wonder what's still left to do here at all:
Vulkan is just an frontend API (state tracker) - at least in Mesa (no idea what Nvidia's doing here), it all goes into the same pipeline. The interaction with the windowing system is just about creating/passing/syncing buffers - that's what DRI is for.
Haven't checked all the details yet, but to me it all seems to be on Mesa side.

[mSparks43]

One thing I would suggest is that an X11 extension to add vulkan layers to windows would:

Any suggestion how it would look like ?

Actually, I wonder what's still left to do here at all: Vulkan is just an frontend API (state tracker) - at least in Mesa (no idea what Nvidia's doing here), it all goes into the same pipeline. The interaction with the windowing system is just about creating/passing/syncing buffers - that's what DRI is for. Haven't checked all the details yet, but to me it all seems to be on Mesa side.

vulkan has the option to add vulkan layers to the pipeline, these can do things like debugging, compute, change colorspace turn output into a video stream whole load of stuff I've only barely looked at.

I do know this is how gamescope is adding its hdr layer to wine X11 games

Its also how reshade works on windows.

I imagine an X11 extension would let an application check for permission then do all this on the x server it is connected to.

[metux]

vulkan has the option to add vulkan layers to the pipeline, these can do things like debugging, compute, change colorspace turn output into a video stream whole load of stuff I've only barely looked at.

Isn't this just an API concept (on client side) for easier composition of whole pipelines by some prebuilt building blocks (so one doesn't have to add all the invidual steps on his own) ?
Does that need any special involvement on Xserver side ?

Unless I'm totally mistaken, the direct involvement of the Xserver here should just be (oversimplified):

• getting metadata on the target display (geometry, color space, ...)
• acquire compatible frame buffer for the target window
• submit the finally rendered buffer to the display server, so it can blit it into the actual display framebuffer
• some sync/fence signalling

Anything in between, IMHO, shouldn't be of any concern by the display server - it's just getting the final frames for the individual windows.

I do know this is how gamescope is adding its hdr layer to wine X11 games

Does anyone know how those game actually do the HDR stuff by the windows API ?

Its also how reshade works on windows.

What exactly does that do ?

[Quackdoc]

It's not hard to do vulkan layers, but first xlibre needs to support it getting colorspace data from the application, triggering HDR on the monitor, and doing the basic transforms.

Context because the terms HDR and SDR are dumb.

a color space is Gamut/primaries + transfer/gamma + whitepoint. As far as I, and the compositor cares, the most "unique" part here is the transfer and gamut. the "HDRness" of colorspaces as far as I am concerned, and most users are concerned, comes from the transfer, but this isn't really relevant because content is done in colorspaces

Most legacy un-colormanaged applications are either bt.1886(rec709) which is common on TVs, or sRGB which is more common on PC displays. These are "SDR" colorspaces. There are others, but for uncolormanaged or "SDR" applications, this is all we really care about. Colormanaged applications can be treated differently (and should be.)

The common HDR colorspaces are rec.2100 with either HLG or PQ transfers. HDR metadata can be added onto it to modify them, but it's not a hard requirement to handle. when it comes to displaying, HLG is probably the "easiest" to do, but PQ is by far the most common.

Games often use scRGB colorspace which is a linear transfer with the primaries of sRGB and doing some weird hijinks with values to expand it. You need to convert scRGB to rec2100 with either of the transfers because no monitors use it. (linear is a lot of data :D)

the current method compositors seem to be going with now to implement SDR->HDR is to have a dedicated SDR plane on the GPU, then use operations to transform that into "HDR" Presumably using a lut, but I don't know what all operations are available to work with here (https://melissawen.github.io/blog/2025/05/19/drm-info-with-kms-color-api).

The actual specifics of the mapping should be user configurable (or compositor configurable, not really sure here) There are a lot of more nuanced things to think about like 'to what luminance do you make "SDR" to "HDR" ' which really should be user configurable.

I think modeling the color data based on the wayland protocols themselves is fine, they are sufficiently detailed and staying in line with them will only serve to help applications port to xlibre.

[metux]

It's not hard to do vulkan layers, but first xlibre needs to support it getting colorspace data from the application, triggering HDR on the monitor, and doing the basic transforms.

So should we add a colorspace parameters attribute to windows or pixmaps ?
Or send them with each frame ?

[mSparks43]

generally agree, but a lot of that is also already done a very long time ago, but the documentation is poor or non existent or just missing. a good place to start is probably the colord source code - what is in there already, what can be hardware accelerated with e.g. vulkan layers, what needs improving/adding.

Oh, and who is going to pay for the $20,000 displays you need to actually barely see if it actually works..

color is a very, very hard topic, these "hdr on" toggles wayland compositors are adding are 100% gimmic, 0% useful. You can tell that by the only calibration software for Linux is X11 only.

[rc-05]

Could be the DeepColor X11 extension proposed by NVIDIA be a potential starting point for implementing HDR support?

[metux]

Could be the DeepColor X11 extension proposed by NVIDIA be a potential starting point for implementing HDR support?

Perhaps. But maybe we don't even need to go that far, if we can live with 10bpc and 2 bits alpha.
The major problem here is current protocol isn't designed color values above 32bit . But 10bpc would still fit in.

Not sure what exactly they're wanted to transmit via window properties. If it's about frame/scene specific gamut, then properties might not be the ideal way to do that. Needs some deeper thoughs.

[rc-05]

Do you happen to have some example code for testing ?

No, sadly. However, it is possible to see how Chromium-based programs and Firefox suffer from using 10-bit color depth.
Firefox will slow down to a crawl (especially noticeable with higher refresh displays) and Chromium will display the wrong colors. Steam will outright crash if 10 bit color depth is enabled, probably because of the afromentioned assumption about the color depth being set to 8 bit.

See the Arch Wiki page for the AMDGPU driver. I do not know if this problem is present with NVIDIA GPUs.

Looking back, this is not really a X11 problem per se but rather a client one due to the 8 bit color depth assumption of said X11 clients.

[Lyky35]

While i may not be correct on all points, what you want is to detect if application wants to send HDR metadata, understand the metadata signal, and if you are in HDR environment that's great, don't force it to applications to be in 10bit, and vice versa for SDR.

• But my colors, my brightness etc

Well if you are in SDR and you have 10bit content use tone mapping to make them look good on 8bit.
If your are in HDR and software doesn't do 10bit, it will still look fine. But allow user to create his own tone mapping / color profile for application or globally. i.e. adjust contrast, and brightness. If tone mapping goes anywhere then same thing can be used for SDR content to up it to HDR per your monitor profile.

(Browsers chromium based, firefox do not really support hdr and they do not send hdr metadata - their implementation is broken because they don't send metadata, and they do try to send 10bit color space instead.)

The wrong colors *"completely bugged colors" appear because they are trying to use wide gamut, and x client, windows, wayland whatever doesn't support wide gamut they understand only sRGB range. (mac does use wide gamut.) Thus its likely overflowing the bit section allowed for color information of pixel. *The correct solution would be to allow user to select color profile (sRGB, Adobe RGB / wide gamut, rec2020 and so on) they are working with; and clip color data on the range their profile supports with nearest maximum in your color gamut.

*if this is done right, and you can select correct color gamut - xlibre will become the choice for photographers hehe.
(I think support for wide gamut is the golden standard, and the way HDR should really be approached.)

[Quackdoc]

I think you are mixing up some terms.

bit depth is not directly related to color. a 0.5 rgb in 8 bit and in 10 bit are the exact same color. "HDR" as the term is commonly used is not strictly contingent on having 10bit colordepth or greater.

When it comes to display output, you have 1 colorspace. You cannot just mix images and expect them to look good. if you have a wide gamut display pipeline, you need to actively convert sRGB to the wide gamut.

Unlike the first example an 0.5 rgb is a different color when comparing gamuts. The display server, in this case xlibre needs to manage transforms between gamuts and transfers.

EDIT: and ofc, xlibre would ideally be able to handle mixed clients, IE. clients that do 8bit and 10bit

[rc-05]

But allow user to create his own tone mapping / color profile for application or globally. i.e. adjust contrast, and brightness. If tone mapping goes anywhere then same thing can be used for SDR content to up it to HDR per your monitor profile.

This could be perhaps done together with colord, since that allows a user to choose the color profile?
I am just brainstorming ideas, as always, correct me if I am wrong or there is a better approach. 🙂

I think you are mixing up some terms.

bit depth is not directly related to color. a 0.5 rgb in 8 bit and in 10 bit are the exact same color. "HDR" as the term is commonly used is not strictly contingent on having 10bit colordepth or greater.

When it comes to display output, you have 1 colorspace. You cannot just mix images and expect them to look good. if you have a wide gamut display pipeline, you need to actively convert sRGB to the wide gamut.

Unlike the first example an 0.5 rgb is a different color when comparing gamuts. The display server, in this case xlibre needs to manage transforms between gamuts and transfers.

EDIT: and ofc, xlibre would ideally be able to handle mixed clients, IE. clients that do 8bit and 10bit

I see... Thanks for the clarifications! 🙂

[Lyky35]

bit depth is not directly related to color. a 0.5 rgb in 8 bit and in 10 bit are the exact same color. "HDR" as the term is commonly used is not strictly contingent on having 10bit colordepth or greater.

If you truly have 10bit image, your whites, your blacks or any other colors won't match unless you can understand / translate 256 x 256 x 256 color matrix into 1024 x 1024 x 1024 color matrix. The color white in 8bit is represented as 255 x 255 x 255 while same white in 10bit is represented as 1024 x 1024 x 1024. You might be able to get near the right color but you won't get same color.

The HDR as it is functioning right now on windows is 8bit of color data + 2bit in separate metadata that typically describe how bright that color should be with 4 settings (0% 25% 50% 100%) - (i might be wrong, but playing with metadata - i.e. changing those 2 bit values produced exactly that - the color depth - generation of more colors is typically only an illusion by dithering.)
*(i'm running a decent monitor pg32uqxr which has wide gamut mode, and does 10bit natively - so its not just a limit of a certain monitor)

When it comes to display output, you have 1 colorspace. You cannot just mix images and expect them to look good. if you have a wide gamut display pipeline, you need to actively convert sRGB to the wide gamut.

To correctly display, and use 10bit color or more we would have to sit on wider gamut and translate the lower and higher bit address matrix to assign the correct color value from the gamut the display handles. Thus it would be better to work in 32bit address space for color depth even though we won't be using it.

Unlike the first example an 0.5 rgb is a different color when comparing gamuts. The display server, in this case xlibre needs to manage transforms between gamuts and transfers.

Yes.

I am just brainstorming ideas, as always, correct me if I am wrong or there is a better approach. 🙂

Thats right i'm not what you call a professional either. Just enthusiast hoping for something good. - and reason to not buy mac or use windows kvm to just play hdr content.

[Quackdoc]

I think implementing the DeepColor extension is a good idea or at least being based on it. Realistically speaking, I think supporting FP16 is desirable anyways and since xlibre will need to put in some effort in supporting mixed clients anyways, it seems like a good idea to do that while keeping FP16 RGBA formats in mind.

[callmetango]

Thank you very much for your contributions! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the Good Ideas For Later category.

As far as the matter itself is concerned, we will defentively have a look at it.

[Quackdoc]

Since it was brought up on the telegram and not brought up here, the linux kernel now has a color pipeline API that can do transforms on images utilizing planes.

Xlibre will be able to composite SDR applications on one or more planes, use the colormanagement API to make said planes "HDR" ofc, this relies on supporting overlay planes. https://github.com/torvalds/linux/blob/master/Documentation/gpu/rfc/color_pipeline.rst

although hardware dependent, the general idea of grouping SDR applications together and applying an "HDR Conversion" to them is the same regardless, This is hardware accelerated, however this should be developed in a way that makes grouping without "hardware planes" possible.

This would need to be spun out into it's own topic on how to handle overlay planes, but however that discussion goes, being able have a "logical plane" that can be represented either just internally on x11, or in hardware would be immensely useful.

[cepelinas9000]

"A picture is worth a thousand words", that this topic is not forgotten:

What I want to show after patching driver:

• washed out colors with 400nit brightness - because there are no tone mapping at all. I want demonstrate that fundamentally pipeline is working (pushing pixels).
• screen framebuffer is in 16 bit float format (HDR mode)
• The drm connector have correct properties: BT2020_RGB color space and sent hdmi hdr metadata frame - EDID parsed correctly
• Monitors info shows - receiving HDR signal
• forgot to open terminal and show that running on xlibre... (my bad)

Obviously there needed much more for hdr...

[metux]

Not yet, firstly I need to figure how to create vulcan vkrots layer (https://github.com/misyltoad/vkroots) to demonstrate bare minimum working implementation using mpv - it is very similar what gamescope is doing https://github.com/ValveSoftware/gamescope/tree/master/layer

I'v been thinking about the code that's switching the display into HDR mode. This could be masked behind some experimental flag, so one could explicitly enable it for experimentation.

I'd also like to try out what it does on my machine (X1 carbon 6th gen) - no idea whether it already has some actual HDR support.
Did you already put this code somewhere on GH ?

[cepelinas9000]

Here: https://github.com/cepelinas9000/xserver/commits/wip/x11hdr/
Is not something even remotely ready: for curious how hdr is turned on, you will be interested around https://github.com/cepelinas9000/xserver/blob/ff4e12ef8d759aa6ea9c6a694a76bee5e287becc/hw/xfree86/drivers/video/modesetting/drmmode_display.c#L5148 and https://github.com/cepelinas9000/xserver/blob/ff4e12ef8d759aa6ea9c6a694a76bee5e287becc/hw/xfree86/drivers/video/modesetting/drmmode_display.c#L3291
If you to check out what happens (there are no functionality to turn off hdr - only restart helps !!!).
Start with following config:

Section "Screen"
    Identifier "default"
    HDR "16f"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

note: my high level idea - create HDRColor visual for surfaces with transformation (this one requires some smart workaround - because what I saw vulkan uses screen visual) and leave rest system in sdr 8bit mode for maximum compatibility
I understand it can be perfectly used setting real framebuffer format and leave window managers to figure out what to do with depths like 64bits and so on

[metux]

thx. I've identified few things we should do before, eg. a clean xf86InterpretEDID() replacement that's also capable of parsing extended EDIDs (thus needs size parameter), cleaning up edid.h, etc, etc.

[metux]

X11Libre/xserver#1881

[jmgilbertNe]

Just so everyone is aware, the correct transform for transforming sRGB-encoded content to PQ-ready HDR content is this :

linear_to_pq(rec709_to_rec2020(sRGB_to_linear(sRGBcolor)) * 80.0 * user_scaling_factor)

user_scaling_factor is typically something in the range of 2.0 to 3.0 because most people think that the standard 80.0 conversion factor is too dark. That was a standard user complaint when MS first implemented HDR in Windows 10 and they added a SDR application brightness scaling slider in the control panel to fix that.

As for how Windows implement HDR, it does no magic of the kind 8-bit plus 2-bit metadata. It just outputs straight HDR10, i.e. 10-bit per channel PQ output with Rec.2020 primaries. For SDR applications, it uses the formula I gave above.

For testing, I would testing games like Baldur's Gate 3 on Proton as, when I implemented HDR for that game, I used querying of DXGI to determine whether HDR was enabled in Windows Control Panel or not. I did that even for the Vulkan renderer of the game because the Nvidia Vulkan driver on Windows doesn't respect the HDR-enabled setting when you request a HDR color space and simply enables it under your nose even if the application is running in windowed mode which causes all sorts of issues like blown out desktop (SDR white maps to 10000 nits in PQ) which then triggers heavy local dimming in the monitor and heavy power usage in older HDR monitors. Blame Nvidia.

It's also worth noting that Chromium on Windows totally does support HDR swap chains. With a good HDR monitor, like the ASUS PQ32UCX-R, and HDR properly enabled in the browser, this website is a gold HDR test on Chromium: https://gregbenzphotography.com/hdr/ as it tests UltraHDR jpeg support in the browser. If the browser and the monitor both support HDR then Key test #1b will display picture of a dog but if either one doesn't then a picture of a cat with red text "No HDR" will be displayed. The website already explains how this trick works so I won't repeat it here.

Hope that helped,
Jean-Michel

P.S: HDR->SDR transform: the correct way to do that is very subjective to each person and might better be left to application developers or, at least, as something that is very optional.

P.S 2: HDR->HDR transform: unless the goal is to handle misconfigured monitors that interpret the signal as non-standard, but common in filmland, PQ-P3 then it's not that great of an idea either. It is true though that there are some cheap brands of HDR monitors that are set by default on this setting and this can be noticed using the Windows 11 default blue flower background which will appear blue in SDR and on a correctly configured HDR monitor but purplish on a badly configured HDR monitor.

[jmgilbertNe]

Please do not create dynamic HDR metadata when the source application doesn't send any. This might be fine for a video player but it will totally mess with HDR games. When working on Baldur's Gate 3, we didn't have dynamic HDR metadata because Windows doesn't support dynamic HDR metadata. We also wouldn't have been able to use HDR if the OS had messed with the game visual by creating fake dynamic HDR metadata. It would also mess with content creation applications like DaVinci Resolve which assume that the dynamic HDR metadata is created in a post-process phase.

[jmgilbertNe]

The compositor could then choose to do a best-effort approach for just one (fullscreen) window (and leaving the other windows a little bit garbled) or do the full color transformation for all windows/surfaces (way more expensive).

The best approach is to let the user specify that HDR should be enabled display-wide in the config file. Then you can go and add Xlibre-compat patches in Wine and Proton to detect support for XLibre that will route the emulation of this kind of DXGI code, the standard detection pattern on Windows, to the XLibre APIs:

` // Having determined the output (display) upon which the app is primarily being
// rendered, retrieve the HDR capabilities of that display by checking the color space.
ComPtr output6;
ThrowIfFailed(bestOutput.As(&output6));

DXGI_OUTPUT_DESC1 desc1;
ThrowIfFailed(output6->GetDesc1(&desc1));

m_hdrSupport = (desc1.ColorSpace == DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020);

`

With this idea, it would work the same as on Windows. The desktop + SDR applications would be upconverted to HDR using the formula I gave in a reply to another post and HDR applications would present their output unmodified. Windows does not let applications enable HDR output when the monitor has HDR disabled but, if you want to support that, then you will have to figure out a solution.

[Lyky35]

Please do not create dynamic HDR metadata when the source application doesn't send any. This might be fine for a video player but it will totally mess with HDR games. When working on Baldur's Gate 3, we didn't have dynamic HDR metadata because Windows doesn't support dynamic HDR metadata. We also wouldn't have been able to use HDR if the OS had messed with the game visual by creating fake dynamic HDR metadata. It would also mess with content creation applications like DaVinci Resolve which assume that the dynamic HDR metadata is created in a post-process phase.

It has to be a user-choice of what kind of hdr they want as mentioned.

[callmetango]

The author of this top-level comment is no longer involved in the XLibre project. Unfortunately, we cannot vouch for the accuracy of this information and therefore advise you to view it critically.

[cepelinas9000]

It's worth noting that MPV is perfectly fine with displaying HDR without the need for the compositor to acknowledge metadat, you should be able to test this using mpv Video.mpv --no-config --vo=gpu-next --hwdec=vulkan-copy --target-trc=pq --target-colorspace-hint=yes

On tested videos looks like real hdr (there are chance not all pixmaps in pipeline have correct drm format or glamor swizzle. My monitor only have wider color gammut).

There no extra processing - here proof of concept rudimentary hdr:
use https://github.com/cepelinas9000/xserver/tree/wip/x11hdr branch
and add https://github.com/cepelinas9000/VK_xlibre_layer vulkan layer

[v-fox]

What the hell is going on here: why some anonymous guy suddenly banning comments from the leader of the project and saying "he's no longer involved"? Who's "we" then?

[rc-05]

More than banning them, comments specifically from @HaplessIdiot are being hidden because he is no longer involved with XLibre for some reason.

[Lyky35]

@metux can we get some clarification? whats going on.

[metux]

This wan't about me, but somebody else who unfortunately had to be banned.

[metux]

Addendum: I'm extremely unhappy about this being necessary, hoped we'll never had to do such steps, but he just had done so many inacceptable things, and no correction in sight.

[callmetango]

Easy @v-fox. This "some anonymous guy" is me, @callmetango. I "happen to" be an XLibre maintainer. You can see it here for example:

Or at the start page of X11Libre · Discussions · GitHub or the public activity of my callmetango · GitHub profile you linked to. Or ask Google.

I didn't say that @metux is no longer involved, but I marked comments and comment threads started by @HaplessIdiot as “outdated.” As mentioned above, we (metux, myself, everyone at the XLibre core team) cannot guarantee their accuracy. That was one of the reasons why we had to part ways with this contributor. There were others, but we don't want to talk about them publicly so as not to ruin his future.

As metux has already said, it was a difficult decision for us, and we are very sorry, but unfortunately all our patience and efforts to resolve the situation have not led to the necessary improvements.