Work-in-progress spike for HDR10 in X11

[reaperx7]

I spent some time researching how to do this and might have a framework drafted that might be usable for adding HDR10 support into X11, albeit, this is WIP code in framework only and is not intended to be functional, but useful as a reference. I attempted to duplicate how wayland uses color-management-v1 protocol in standard c code. Currently, my knowledge of X11 and x-server and driver handling is extremely limited, but I was able to understand the workings of this system to a point of basic knowledge.

I want to offer my sample code and ideas to @metux to use as a basis for implementing HDR10 in X11, to do with as he pleases. The code is BSD 3 Clause licensed for the sake of sample code ownership ONLY, and I will defer license and ownership if the code is used in anyway to incorporate HDR10 into X11 in any capacity, even if reference only.

I only hope this can be useful in some way. Even if it's just an idea. I have not attempted to incorporate this in any capacity as I lack knowledge of how xserver works, but did use the API documentation as a reference of where to begin.

All the sample code can be accessed here and is free to use:

https://github.com/reaperx7/HDR10-X11

If it doesn't help, then maybe it can serve as inspiration to someone who can make HDR10 work in some capacity.

[metux]

Feel free to implement it in your own branch/fork, then we'll can have a closer look at it :)

Some comments on your current WIP:

• SetWindowHDRMetadata() --> should use devPrivate's (manages extra data in various Xserver resources)
• xhdr.c --> should use protocol structs like we already have (see eg. extension headers on how it's done)
• ProcXHDRQueryHDRCapabilities() we can't use modesetting's private data, can put this flag into screen's devPrivate's

Maybe you can start writing a minimal extension (take some simple one as example, eg. xfixes). Since it's likely being extended over time, it should have a QueryVersion operation.

And we need a protocol spec, of course :)

[CustardEddy]

Please correct me if I'm wrong, but the protocol itself support up to 16-bits per colour channel, so the issue is a combination of adding HDR10-ready drivers and suitable applications?

Sanity check: Is it not possible to (correctly) implement HDR10/HDR10+ within the existing protocol?

[reaperx7]

I'm working on it as I go. The Color Management code from Wayland is a bit awkward and based entirely around xml, not C, so translating xml stuff to C is... Trying. My skills in this are college grade so don't expect a miracle. C was not my best strong suit. My passing grade was a D+ and I won't say I didn't try. I read the API documentation and worked from that as well, so it's... Interesting to say the least how this will even work.

[reaperx7]

Please correct me if I'm wrong, but the protocol itself support up to 16-bits per colour channel, so the issue is a combination of adding HDR10-ready drivers and suitable applications?

Sanity check: Is it not possible to (correctly) implement HDR10/HDR10+ within the existing protocol?

It can be implemented in the current drivers (modesetting, amdgpu, intel, and maybe nouveau) and server itself but it does require some reworks to the color management system and adds a new entire process for xhdr as well as headers to reference around the code by drivers and the color management system...

Another reason why rust language is a bad idea for X11 and why C code is better in this instance.

The API documentation says it's doable. It doesn't even have to be an extension, but an expansion of the color management system to be able to handle and process 10bpp color schemes and maintain 8bpp compatibility. You can even make to toggle capable with an entry in xorg.conf to enable 10bpp and even a detection for HDR10 like

Option "HDR10_Enable" "boolean"

And then enable it for the monitor system also.

Right now the problem is finding the cleanest way to do it. Mainly why I only published some rough draft code as a framework to reference, and didn't do a full git clone of the code and start doing patchwork and make something entirely broken.

[SuperDuperDeou]

The API documentation says it's doable. It doesn't even have to be an extension, but an expansion of the color management system to be able to handle and process 10bpp color schemes and maintain 8bpp compatibility. You can even make to toggle capable with an entry in xorg.conf to enable 10bpp and even a detection for HDR10 like

Option "HDR10_Enable" "boolean"

And then enable it for the monitor system also.

Right now the problem is finding the cleanest way to do it. Mainly why I only published some rough draft code as a framework to reference, and didn't do a full git clone of the code and start doing patchwork and make something entirely broken.

You could simply always use 10 bit per pixel internally, since the conversion between 10 bit and 8 bit is just a bit shift with no information loss. It's not the best solution for performance, but it's a solution.

[reaperx7]

There are a few ways but the problem is 10bpp has to be processed separately from 8bpp and it needs a specific handler for this process to work. You basically can use HDR10/10+ but you need the metadata to be processed to handle the management. Unfortunately, this will mean that xorgproto and possibly libX11 will need modifications.

You need a protocol handler.
You need a process to manage the data.
You need to process the data.
You need an interpreter to handle reading the data and saying this is SDR8 and this is HDR10.
You need a system in place to automatically register the data as HDR10 if it's HDR10, with a default fallback to SDR8.
You need a driver support system in place to help the GPU understand the data (amdgpu, modesetting, intel, and maybe even nouveau).
You need also support systems in Mesa and maybe even Wine to handle translation of HDR10/10+ between various functions.
And probably you need a way to reference the handling.

This is a significant upgrade needed to X11.

I'm not saying it's impossible. I'm saying it's just a lot of work.

Do I think it can be done in 10 years? Yes.

I believe with the right people who are skilled with the code, not me of course as this is just a reference draft that probably won't work, they could make it work in less than 3 years, maybe less than 1 if we could get someone skilled with HDR10/10+ rendering and knows how X works.

My thing is... FreeDesktops had the ability to do this. They're more skilled with Xorg than anyone. They just got complacent and lazy in maintaining the maintenance. Which is very stereotypical of Red Hat. They see something old and outdated, and even if it works, they want something better and less to deal with.

They didn't want to do the work to add HDR10/10+ support because of what it would entangle. Was it going to be a lot of work? Maybe. But they could have had HDR10/10+ added with effort in less than 2-3 years tops.

[seacat17]

Dude, your W is too big for GitHub to handle.

I know I'm not contributing much but I'm just gonna say it - keep going guys. I love you all <3

[reaperx7]

Dude, your W is too big for GitHub to handle.

I know I'm not contributing much but I'm just gonna say it - keep going guys. I love you all <3

we're trying... at least we are trying.

[CustardEddy]

Dude, your W is too big for GitHub to handle.
I know I'm not contributing much but I'm just gonna say it - keep going guys. I love you all <3

we're trying... at least we are trying.

You've made a bigger contribution than me. 😄

Don't apologise for a "lack" of skill or your grades in college. I started as a system programmer, but haven't used those skills in anger in ~15 years.

Have you considered sitting down and describing how HDR10/HDR10+ work, in a distilled way? It's extra work, but it will do 2 things:

1. Help you check your knowledge
2. Serve as documentation for folks like me, who know less than you do 😄

I'll try to connect with you directly to see if we can work on this together.

[callmetango]

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

This is to further discuss the spike as things evolve and later on make a decision on how to apply the gathered knowledge to the XLibre Xserver resp. drivers code.