Wayland Color Management Protocol Might Finally Be Close To Merging

[oiaohm]

Points (2) and (5) are the ACKs, points (4) and (6) are the ones that require implementations, no?

Yes.

Its the 4 and 6 when you read carefully you can get away with 1 server and either 1 or 2 clients to tick the implementation box for include. So a single usable implementation at time of include and that the bare min. Please note 4 and 6 does not say the parts that make up the 1 server and 2 clients have to be from multi different members.

The ACKs is the harder to get. ACKS are more we have already implemented or agree to implement it in future. Problem is how far into the future is the agree to implement it. Gnome has a lot of things they have put ACKs on they have not implemented for end users yet.

[MrCooper]

Does this mean 16 bit color support will finally be a thing for wine?

So... does this allow us to run 16-bit colour games on 32-bit display servers?

The core Wayland protocol has always supported that, doesn't require this colour management protocol. A Wayland client can use any supported format for its surfaces, independently from what the compositor chooses for its output format.

Or is it only for managing colour calibrated displays?

Well FWIW only a minority of people need color management. You basically need to calibrate your monitor.

I just plug the monitor, check refresh rate and resolution, adjust the contrast and brightness for an even distribution of all tones on the monitor's controls. And, maybe, play with the color saturation a bit. That is all. I never found color management useful on an ordinary consumer monitor. If that is a professional monitor specifically for content creation, of course.

What you guys are describing isn't what this colour management protocol is about; in fact, that doesn't require any Wayland protocol at all. Wayland compositors such as mutter have supported applying monitor calibration profiles for years.

The colour management protocol allows the client to describe to the compositor what colour space the contents of a surface are based on. This allows the compositor to display the contents correctly under all circumstances, even while multiple surfaces are visible with contents based on different colour spaces. This is something which X has never supported.

It also allows the client to use colour spaces which extend beyond sRGB, i.e. wide gamut & HDR.

The difference is that with Wayland Protocols, two years of discussion happens before anybody is allowed to implement the protocol even in an experimental stage.

That's never been true.

The point of Frog was that as soon as the protocol was introduced, it could be put into production to test it's limitation and flaws instead of just theorizing about it for 2 years before finally deciding "eh, it's probably okay", making 1 tiny change, and saying it's okay to implement. Being tested in the real world brings out the technical flaws of a protocol much faster than just theorizing, but due to the nature of the Wayland Protocols setup, that's hard for them to do on various levels.

Experimental implementations of this colour management protocol (using the "xx-" prefix) were out in the wild already before the Frog protocols brouhaha broke loose. Now the experimental protocol mechanism has been added as a more formalized way to do that.

I finally can play HDR videos with MPV without adding ENABLE_HDR_WSI=1?

Not directly. It might require MPV itself to use this colour management protocol, or at least the Vulkan layer to use the finalized protocol and expose HDR without the environment variable.

Yay, Wayland on track to reach feature parity with Windows 3.11 for Workgroups in 2050!

TIL that Windows 3.11 supported wide gamut & HDR and displaying windows using different colour spaces correctly at the same time.

[DMJC]

The core Wayland protocol has always supported that, doesn't require this colour management protocol. A Wayland client can use any supported format for its surfaces, independently from what the compositor chooses

Thank you! This is what I've been trying to find out for a while. I have one fringe case game. I'm on Wayland with MATE 1.28 it's excellent. Wayland isn't the issue and hasn't been for a while. I'm just waiting for screenshot support in apps like gimp/wayfire to catch up now. GPU hotplugging support is already working brilliantly. It's a massive leap forward over X11.

[MorrisS.]

What about USB game pads? When can we control the Wayland pointer with those? There used to be a X driver for the original xbox controller iirc

It is provided on system manager of Plasma. tExR43Q.png

[caligula]

What you guys are describing isn't what this colour management protocol is about; in fact, that doesn't require any Wayland protocol at all. Wayland compositors such as mutter have supported applying monitor calibration profiles for years.

The colour management protocol allows the client to describe to the compositor what colour space the contents of a surface are based on. This allows the compositor to display the contents correctly under all circumstances, even while multiple surfaces are visible with contents based on different colour spaces. This is something which X has never supported.

It also allows the client to use colour spaces which extend beyond sRGB, i.e. wide gamut & HDR.

But how efficient is that? Doesn't wayland use xml quite a lot? I've seen some serialization formats where each pixel is stores as xml entity and rgb attributes. What a waste of space.

[anda_skoa]

Doesn't wayland use xml quite a lot?

Not at runtime.

Like X11/xcb or D-Bus it uses XML to describe the interfaces between server and clients.

With tools that then generate APIs so that most developers don't have to deal with the messaging and wire-format parts.

[oiaohm]

But how efficient is that? Doesn't wayland use xml quite a lot? I've seen some serialization formats where each pixel is stores as xml entity and rgb attributes. What a waste of space.

https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format

The wire-format of wayland is not XML as shown above..

Wayland XML is really way of doing like interface description files and documentation for those interfaces in a single file. Yes this is like X11/xcb, d-bus and others.

https://wayland-book.com/libwayland/wayland-scanner.html

Yes this tool takes the XML of the Wayland protocol and makes the C code that generates the wire protocol. A different tool can take that xml file and make manual for that section of the protocol.

One of the big problem of doing interface description files and documentation for those interfaces as two files is they have habit of falling out of sync. This is not a free lunch of course a interface description file without all the documentation would speed up building libwayland-client and libwayland-server a little bit. Notice building this makes zero difference on applications using libwayland parts performance because the XML is not in the binaries.

[caligula]

That is something the developers had established for X11 development and applied again when working on Wayland.

XML is a good compromise for something that should be both machine and human readable.

It is a widely used approach, e.g. for D-Bus, SOAP, SCXML (state machines), etc.

A significant part of industry has switched from legacy XML formats to schema free JSON. It's great for SPA web apps.

[oiaohm]

A significant part of industry has switched from legacy XML formats to schema free JSON. It's great for SPA web apps.

Remember the Wayland case we are talking about "interface description language" or IDL with Wayland using XML form of a IDL.

https://github.com/vshymanskyy/JIDL?tab=readme-ov-file#example-idl-file

JSON IDL is not exactly the nicest.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml?ref_type=heads

Turns out XML IDL is very nice to read. JSON IDL becomes very hard to read very quickly.

The opening and closing statement of XML instead of just {} like JSON has does have some major human readability reasons.

Look at the json example how would spot a missing }.

https://learn.microsoft.com/en-us/windows/win32/com/anatomy-of-an-idl-file

The reality is json IDL you end up back at old school painful to debug IDL files.

caligula you are right that lot of industry has changed to scheme free JSON one of the problems is you cannot do IDL files without schema even in JSON. Because a IDL file need to be transformed from what it is to programming code be it C/C++/python....... IDL file is not the final product this is why all IDL files have to have some form of schema or the transformation system not going to work.

Remember the XML IDL files of wayland only effect application building where they are processed into C/C++/... what ever require programming language in the targeted use case. XML turns out to more human readable than JSON and simpler for human to spot errors..

There are particular corner cases where XML fits very well. XML fits very well for IDL files.

JSON advantage over XML is that is more compact but that not helpful for a IDL file due to how it used. Human will be reading and manually editing iDL files.

[anda_skoa]

A significant part of industry has switched from legacy XML formats to schema free JSON. It's great for SPA web apps.

Do you have an example of an interface definition in JSON?
So far I've only encountered it as a data transfer format.