NVIDIA Proposes "DeepColor Visual" Extension For X.Org Server, For HDR On Linux

[starshipeleven]

Wayland almost leaves all responsability to the compositor or the developers of a desktop environment, so basically they have more stuff to worry about, seeing how inconvenient wayland is been from the start isn't looking any good.

FYI: a Wayland compositor is basically a Xorg without the legacy crap.

Every freaking game now needs to be ported from X to wayland for it to perform well,

Wrong.

[tuke81]

The Nokia N9 from 2011 was using Wayland and Qt's support for Wayland. At that point it was already 5 years old and distros had promised to switch to Wayland and then dropped it when it wasn't ready for anything beyond embedded.

No it was not. Meego on Nokia N9 was still on xorg+Qt, Jolla and it's Sailfish OS is wayland+Qt(from Mer of course). I don't reckon hearing you could install Mer on N9, but my memory might deceive me on that.

[bug77]

Why would anyone need hdr, content is missing.
http://www.pcgamer.com/what-hdr-means-for-pc-gaming/

I'd like that for my vacation photo editing. HDR photos are a thing of beauty. Professional rendering software is sure to pick up HDR quickly (if it hasn't already). Content will come, this is not the usual chicken and egg Hollywood plays with the gimmick of the year (be it HD, 3D, UHD or whatever). Come to think of it, games are about the last thing I feel could put HDR to good use. They can use HDR, but it will be a while till makers learn to wield HDR correctly.

[TheOne]

FYI: a Wayland compositor is basically a Xorg without the legacy crap.

Exactly, so now gnome have its own implementation, kde still working on it, and there is going to be more... and what is the gain? This is like everybody writing its own Xorg instead of using a single implementation.

Wrong.

Was the xwayland overhead that caused games frame drop fixed?

[carewolf]

There seems to be at least one bit missing from the protocol.

pal666 Colour spaces did not start with the current batch of video cards.

Yeah, but they used to be similar enough (around 2.0 gamma and sRGB), that it was the job of the application to read the color-space of the display system or screen and adapt to it. With the new HDR "gamma" functions being very different, the display system now needs to actively do something about applications not implementing color-space handling if it is running in HDR mode.

[gwgwg]

A more forward looking approach would be to work on this for Wayland (and preferably sort out their alternate Wayland implementation first).

Wayland doesn't supporting color management, so it makes more sense to add new color capabilities to X, which does support color management and the associated tools. (Not that color management is necessary for HDR, but it certainly complements it.)

[gwgwg]

I'm sure there are other issues with Wayland at the moment too, these are just ones I've got personal interest in and can recall.

Complete lack of support for Color Management, and no idea why it is necessary or how to implement it. The problem is that the Wayland developers have assumed as a point of doctrine that they can hide certain attributes of the display, while still expecting the compositor to do all the rendering. So they can't bring themselves to pass display information such as which display is being rendered to by the compositor (needed because if the compositor is doing color management then it needs to know what color profile applies to those pixels), but nor do they understand what is involved in having Wayland do the color transformations (support for general N plane color to display space defined by the compositor/application), nor can they get their heads around the fact that part of color management is setting up the display hardware state by setting such things as the graphics card per channel lookup tables (they assume that such details will be done "by the compositor" talking to the hardware by some other means, meaning that there is no Wayland protocol equivalents to standard X11 protocols, meaning that color management applications are faced with with having no standard API available to them to implement their functionality, as well as suggesting that it is "impossible" because "security", ignoring completely that the user is ultimately in charge of their own hardware.).

All solvable technically, but Wayland is confounded by its doctrine.

[polarathene]

Complete lack of support for Color Management, and no idea why it is necessary or how to implement it. The problem is that the Wayland developers have assumed as a point of doctrine that they can hide certain attributes of the display, while still expecting the compositor to do all the rendering. So they can't bring themselves to pass display information such as which display is being rendered to by the compositor (needed because if the compositor is doing color management then it needs to know what color profile applies to those pixels), but nor do they understand what is involved in having Wayland do the color transformations (support for general N plane color to display space defined by the compositor/application), nor can they get their heads around the fact that part of color management is setting up the display hardware state by setting such things as the graphics card per channel lookup tables (they assume that such details will be done "by the compositor" talking to the hardware by some other means, meaning that there is no Wayland protocol equivalents to standard X11 protocols, meaning that color management applications are faced with with having no standard API available to them to implement their functionality, as well as suggesting that it is "impossible" because "security", ignoring completely that the user is ultimately in charge of their own hardware.).

All solvable technically, but Wayland is confounded by its doctrine.

Have you raised those issues to the Wayland devs? I don't know where development is discussed, but presumably they have some place where they communicate about what to do. Perhaps they just were not aware of all the things you've mentioned? Doesn't sound like common knowledge

I don't really get the security reason for not allowing certain protocols myself, compositors just implement their own extensions to work around it from the looks of it? Would make more sense to just flag what parts of the protocol are "safe/secure" and which ones are not. Would there be any issue in doing that? Would be nice to have protocols that are more agreed upon rather than compositors implementing similar extensions.

[erendorn]

Why would anyone need hdr, content is missing.
http://www.pcgamer.com/what-hdr-means-for-pc-gaming/

Why would anyone produce hdr content, support is missing.
/s

Supporting HDR is a long effort (it's still a long way from being ready), so they are starting now.

[gwgwg]

Have you raised those issues to the Wayland devs?

Oh, yes - and the result was kind of ugly, even though I thought I was being rather polite, and trying to tread carefully :-) [ It seems far to easy to offend when you start pointing out that the emperor has no clothes. ]

Bottom line was that the only way forward I could see would be to write an extension myself (maybe with help from the couple of other people who also understood the problem) and hope that compositor implementors might adopt it, given some pressure from application writers and users. Given that due to technical requirement it would go against Wayland doctrine, there is almost no chance it would be accepted officially as part of Wayland. Do-able, and yet another project to add to my long list of "nice things to have a go at if there is ever time, or if someone was to pay me for doing it" :-)