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]

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?

[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.

[smj-cc]

There were others, but we don't want to talk about them publicly so as not to ruin his future.

There is a careful balance, between protecting the reputation of others, and protecting your own. It is not always possible to do both. The truth can defend itself.

[cepelinas9000]

For curious what X11 HDR looks in experimental state:

My android camera hates me 😆

Here:

1. XFCE session - SDR desktop @ 50 nits
2. Firefox window blasting 350 nits (SDR content max brightness can be set per window)
3. mpv playing hdr video - here in terminal can see VK_FORMAT_R16G16B16A16_SFLOAT using VK_COLOR_SPACE_HDR10_ST2084_EXT colorspace

[callmetango]

Verrryy nize! 👏

[alkeryn]

how ?

[cepelinas9000]

If you asking technical details: from xserver perspective, it is texture bliting onto frame buffer using shaders (which already done by glamor renderer). Nothing stops to add one or two extra arguments with additional extra matrix multiplications before putting pixels.

As for code, i need to rebase and slightly refactor before putting in my public branches.

[cepelinas9000]

I reached conclusion for question "Can X11 support HDR". Most changes revolves around glamor render for other part is here and there relative tame refactoring.

It lives:
https://github.com/cepelinas9000/xserver/tree/wip/x11hdrV2
and
https://github.com/cepelinas9000/VK_xlibre_layer

Current code - only modesetting driver, minimal parts of glamor render support colorimeter (expect a lot of dark window or sudden dark effects when there are alpha effect used) and render code assumes all monitor hdr :)

When compile xserver and enable in config:

Section "Screen"
    Identifier "default"
    HDR "16f"
    #HDR "10i"

EndSection

And add environment variables for VK_xlibre_layer (only BT2020 linear and BT2020 PQ implemented).

For SDR part, there is __X11HDR_SDR_PARAMS property which tunes any SDR content. If you set on root window - the default values, for windows (you need found that logical output window) it overrides defaults, see https://github.com/orgs/X11Libre/discussions/251#discussioncomment-16089204 for example

xprop -id 0x2000002 -f __X11HDR_SDR_PARAMS 8s -set __X11HDR_SDR_PARAMS "20.00,1.0,1.0,0.0,0.0,1.0"

set 20 nits white point for 0x2000002 window, (parameters are( whitepoint, contrast, saturation, hue, brightness, gamma)

[metux]

@cepelinas9000 do you already have some pieces to upstream yet ?

[alkeryn]

@cepelinas9000 on compositor like hyprland you can dynamicaly switch the monitor to hdr mode when an hdr application is in fullscreen, do you think such things would be possible with your branch?
thanks for the work !

[Quackdoc]

Is there a config here to specify PQ or HLG? Being able to swap between PQ and HLG will be quite nice when this is released, and is something that seems to be missing from current HDR display servers for linux. I think Kodi and MPV can do this right and thats it.

[cepelinas9000]

Is there a config here to specify PQ or HLG? Being able to swap between PQ and HLG will be quite nice when this is released, and is something that seems to be missing from current HDR display servers for linux. I think Kodi and MPV can do this right and thats it.

I thinking extending xrandr to accept something like this xrandr --hdr-mode hdr10i --hdr-tf pq or xrandr --hdr-mode hdr16f --hdr-colorspace yctp --hdr-tf pq. My main concern is HLG tf is relative, PQ absolute - how they interact (with PQ everything simple as it is absolute values, but HLG is relative).

for foreseeable future the Xserver should have colorspace kernel parameter - main reason that modern monitors (i have no modern monitor :) ), can have native ICtCp signal support, instead BT.2020 and it is logical to support

Mathematically these transformations are almost reversible (we can be short of bits or lose precision transforming with ICC curves) and we need all transformations -for monitor and for screen capture.

I imagine at this point to turn hdr could look like this:
xrandr --hdr-colorspace BT.2020 --hdr-tf PQ --hdr-mode 10i or imagine advanced settings in gui 🙃

[Quackdoc]

IMO HLG is a far better transfer function to default to when it's supported. The vast majority of displays simply work better with HLG because display brightness. Not peak but actual current display brightness is taken into account.

You can turn down your display brightness and still maintain the perceptual quality With HLG. you can't really do this with PQ easily.

Likewise, when it comes to composing HLG, it's easier to actually do this with HLG than it is with PQ. which does matter for us because we need to map scRGB and PQ anyways,

[TimothyLottes]

Please keep the old low overhead 8-bit/channel pass-through intact.
Ideas involving forced use of compositors and hidden Vulkan shader passes
is an instant NO-GO for professional use for real-time systems.
We still need vintage 8-bit/channel direct full-screen flip without copy without composite, fully working!

So with whatever new stuff happens, please keep the old stuff also supported!!!!

Discussion of Challenges For Modern Color Calibrated Workflows

In the vintage analog era things had been simple, we used hardware pucks to sample the output of the 8-bit signal, then used that feedback to calibrate the higher-than-8-bit precision VGA 1D LUTs so the better than 8-bit DAC could move all those 256 output steps to where they should be for the associated tonal specification (say for example a gamma 2.2 curve).

In the digital era this old practice for color calibration got broken. For example AMD's HW LUTs are now 12-bit input to only 8-bit output. So using anything other than the identity matrix (ie no change pass-through) implies introducing more banding into the output, because you'd be mapping 2 or more rendered 8-bit steps into the same digital 8-bit output step.

Now note many serious usage cases still need 8-bit/channel output, because they also want high-resolution and high frame rate without using DSC (lossy display stream compression on the output). So moving to say 10-bit/channel isn't necessarily an option (even if the HW supported a 10-bit output in the LUT).

Another serious issue is that you'd see banding with a non-dithered signal at 8-bit, and even higher bit depths with the brightness and contrast capabilities of modern displays. Correct spatial/temporal dithering needs to be applied in a linear space (but simultaneously aware of the output signal space) so it is energy conserving across time. Applying dithering in a non-linear output space does subtle regrading of the output, it doesn't preserve the intended signal. This can be a really serious issue in the darks (on good displays that don't have a step function artifiact around black), when you shift the APL (average picture level) down to support visible higher contrast in a very dark viewing room.

All the new overly complex HW in the scanout block for color calibration and linearizing for overlays/etc, gets this part about correct dithering completely wrong. They are all formulated on the idea one can output a 12-bit signal and do all this processing (1D shaper LUT, 3D color LUT, etc) and then quantize output without correct dithering. So a return to seeing banding on the output.

The crux of all this is that the only CORRECT place to do color calibration on modern hardware is for the application to do it itself: read the measured calibration graphs in the application and send out the post-calibrated output to a RAW pass-through output. Because to implement energy preserving spatial temporal dithering, you'd have to do it in the shader during conversion into the non-linear output signal for the swap-chain. This is something the HW cannot do for you. This is also something you wouldn't want a compositor to do for you either, as that implies extra round trips through memory, etc (high overhead at high fps and high resolutions).

Meaning you'd still want to run the old way, with rectangular windows with NO alpha blending, or alternatively run only full-screen.

[cheako]

As the video said, perfect conversion from one color space to another is possible. As for not having the exact same colors available, even at 16M colors it's impossible to tell the diff for neighboring colors. So for the fraction of a color adjustments that would be introduced, you've got to be kidding me. Obviously color adjusting shader stages should be removed when not using high bit color, so the latency is easily disabled when needed. The other way to remove the color adjusting shader stages is to implement HDR in either the app or the library the app uses.