KDE Begins Laying The Groundwork For HDR Support, Wayland Color Management

[acobar]

We need more maturity in Linux forums and for people to stop beating dead horses everywhere....

Yes, Wayland is here to stay. Deal with it (tm).

This is what I think, too. My hope is that, with time, many things missing will be integrated (I really would like to see basic objects introduced so that RDP become bearable in Linux) and, somehow, Gnome, KDE, Sway and Weston coalesce around a fairly complete librar(y|ies), instead of the "oh, it is just a protocol".

[Quackdoc]

The only problem with those features is that the users with really old ISA, VLB, and PCI era systems can't really run modern desktops anymore. They don't have enough shader performance to do those at real time.

thankfully, they will be able to run in good old SDR mode (and fullscreen HDR), but without those two features HDR desktop is not a good experience.

[caligula]

by the time HDR does roll out, IMO there are three critical parts to get correct

- toggleable normalization that will allow you to adjust the perceived brightness (IE. target nits). this is needed in general, but especially so for people with high nit displays. I like my eyes very much, thank you apple.

- proper color management including adjustable tonemapping. tonemapping in general is largely preference, there will be lots of applications that aren't HDR aware when HDR finally gets supported, it would be nice to avoid what window's situation.

The only problem with those features is that the users with really old ISA, VLB, and PCI era systems can't really run modern desktops anymore. They don't have enough shader performance to do those at real time.

[caligula]

KDE Wayland without colour management is essentially useless in my case, glad this is getting fixed, however, as such a critical feature it should have been addressed earlier.

Like the Wayland fans tell you, it's not such a big deal. Just recalibrate the screen every time you do dual boot. Or write the RGB and other parameters on paper and reconfigure via the OSD GUI every time you reboot to other OS / desktop. Couldn't be any easier.

[TemplarGR]

There needs to be an alternative to Wayland. Wayland is too big and too impossible to do anything useful at this point. We need a new paradigm to handle displays.

We need more maturity in Linux forums and for people to stop beating dead horses everywhere....

Yes, Wayland is here to stay. Deal with it (tm).

[Quackdoc]

What about Arcan and subprojects?

hesitantly optimistic about arcan myself

[archkde]

Is this why Adobe doesnt bother in releasing anything on Linux?

Or as conspiracy theorists say, they dont do it because both Apple and MS pay them under the table of course, to continue ignoring Linux?

It's not that some entities pay Adobe in order to not support Linux, more like no one pays them to support Linux so they just don't care enough.

[timofonic]

There needs to be an alternative to Wayland. Wayland is too big and too impossible to do anything useful at this point. We need a new paradigm to handle displays.

What about Arcan and subprojects?

[Quackdoc]

by the time HDR does roll out, IMO there are three critical parts to get correct

- toggleable normalization that will allow you to adjust the perceived brightness (IE. target nits). this is needed in general, but especially so for people with high nit displays. I like my eyes very much, thank you apple.

- proper color management including adjustable tonemapping. tonemapping in general is largely preference, there will be lots of applications that aren't HDR aware when HDR finally gets supported, it would be nice to avoid what window's situation.

- direct scanout HDR metadata changing. if I have an HLG video and an HDR10 video (PQ with mastering info) the easiest way would be for the compositor to run in pq mode, and map HDR10 and PQ to it (dynamic HDR, (HDR10+ and DV) will likely pose a large issue for quite some time). however, when the application is made fullscreen, it's HDR metadata should take priority.

I have no doubt that direct scannout will get more or less implemented properly, however the other two are incredibly important, the bigger issue is that this will (and should to be fair) be up to the compositor to implement, which means the quality of implementation, and if it even gets done so, will vary greatly

[theriddick]

KDE Wayland without colour management is essentially useless in my case, glad this is getting fixed, however, as such a critical feature it should have been addressed earlier.

Yeah same. Been asking for a long time. The best we've had was some quick solutions with wlroots but only a few desktops use that as backend and they come with significant limitations that the user must manually code/config in essentially.