well, I just checked out Fedora 29 with Gnome. Color management seems to work. Trying to install darktable to run darktable-cmstest. Wayland is definitely running.
seems to work with Xwayland
seems to work with Xwayland
Sure, GNOME 3 implemented support for things like videoLUT access under Wayland (via colord) some time ago, as pointed out by Graeme. Problem is, some important parts of that are GNOME-specific (a few days ago I tried setting up colord-kde under a fairly recent KDE with Wayland, and while working fine with X11, I couldnât get it to work under Wayland at all, probably because essential parts are missing in other components, i.e. in KWin). So, currently, each desktop would have to implement support separately, which is not a good situation (I can tell, because I just implemented calibration support in DisplayCAL for GNOME 3 with Wayland, not something Iâd look forward to having to do over and over for every other desktop environment).
Coming to speak of, there are other things in Wayland that seem like really awkward design decisions (warning, small off-topic rant incoming): Like the decision to remove support for client-side window positioning. I agree with the decision to remove absolute positioning, but the sensible thing to do would have been to replace it with relative positioning, instead of getting rid of it entirely (the way itâs been used by any sane application developer anyway, the argument thatâs been touted about at the time was also nonsense, as window positioning is not about letting apps place windows arbitrarily, but about giving them the ability to express user intent, e.g. to remember last window positions, and as a result, sure enough, automatic window positioning under any Wayland desktop today is all over the place, literally). With the situation now, every compositor that wants to support any form of window positioning needs to implement that as a Wayland extension, which then leads to the usual proliferation of competing implementations (edit: oh, and as an app developer, itâs easy to have window positioning anyway. All you need is the ability to maximize a window, and boom, there you have your canvas where you can place subwindows at any position you like, itâs just a slightly more awkward way to do it if you donât have otherwise the need for it). Thereâs other things I like about Wayland though, the speed is certainly one of them. You probably wonât notice on desktop hardware, but (e.g.) in a VM (VirtualBox) Wayland seems decidedly snappier than X11.
3 Likes
I havenât been able to check fully but suspect even in the Gnome âproprietaryâ implementation there is probably a lot missing especially a way for applications to know which output profile they should use[1]. On the topic of callibration I have been working on a protocol and hope to have soon posted a second RFC on the wayland mailing list (hopefully before the end of the week).
Also on the topic of (off-topic) pet peeves with waylandsâ design mine would be CSD, it doesnât solve nearly as much problems as it creates (IMHO), but sadly that shipped sailed ages ago.
[1] the information from wl_output is a bit to generic to use with colord and even then if the compositor does some weird alpha blending you wouldnât know which can only be worked arround if the compositor itself is color aware
1 Like
so, if I am seeing this right, Xwayland is just a crutch and color management only works with apps that use Xwayland
Well woudlnât sat Xwayland is a crutch on the whole it is a necessary component for legacy support, having said that currently it would indeed be the crutch needed to get some semblance of CM to work (at least how Gnome does it currently seeing from the screendump provided earlier)
Current musings on a Wayland color management protocol. Still very much a work in progress, as there are quite a few details of the âWayland Wayâ to figure out.
2 Likes
it appears to me that Wayland is actually the attempt to create and entirely new operating system which would only use the Linux kernel. Because apps (such as color management, e.g. dispwin) that can be used on the old Linux cannot be used on Wayland-Linux and vice versa, at least not without Xwayland. But the ultimate goal would be existing without Xwayland. This seems to be even a much bigger change than systemd.
@swick can probably give a bit more comments on the client side protocol since I think his is already up for consideration on the wayland mailinglist (IIRC)
For the server protocol (going by your names here) I have the following already wayland-colormanager/cm_wayland_calibration.xml at master ¡ eburema/wayland-colormanager ¡ GitHub apparently it is allowed to use a surface object without a buffer (so long as there is nothing committed AFAICT) so it is possible to give the surface a âroleâ and then in the interface for that âroleâ out an event that gives the buffer size. I decided to go for a full screen buffer size and will probably add that a calibrator should use the wl_surface set_opaque_region hint to tell the compositor what the actual important part of the buffer is (e.g. where it displays user info and the patch)
1 Like
- You canât specify in an extension what happens when the extension is not available
- There is no reason to have anything other than sRGB as default color space
- 3 and 4 describe my current proposal
- There is no reason to disabling color management when there is no ICC profile set. There is EDID information describing the color space and in the worst case sRGB can be assumed.
- Currently reading the CTA-861-G (HDMI HDR InfoFrame) spec and apparently itâs not mandatory for outputs to publish their max brightness. HDR is not easy.
- The HDR parts are not enough to support actual HDR outputs. HDR is not easy.
- The way the word âserverâ is used is misleading given the wayland terminology
- There generally isnât protocols for configurations like display modes, display arrangement, keybindings, mouse sensitivity, etc which is why Iâm against the server_color_management_v1 and output_color_modification_v1 protocols. Compositors use their own configuration system and anything that tries to standardize that fails miserably (and for a good reason tbh).
- Not going to comment on the wayland specific technical problems with the protocol
The good parts:
- The abstract profile is a good idea
- BPC is still missing in my proposal
Iâd be really happy if you would focus on the existing proposal. Itâs gone through a few rounds of improvement and criticism already and it doesnât do anything fundamentally different from what youâre trying to specify. Iâm also working on implementing it in weston.
For the HDR part we might need to look into Freesync2 HDR support since I donât think we can do proper color management without since withouth that spec a HDR display will do tonemapping/color management internally. Freesync2 HDR add a display mode that doesnât do that (their concern is the latency it adds, but this is convenient for us)
See this for more info:
EDIT: Decided to push my latest version to the mailinglist, find it here: [RFC PATCH v2 0/1] Color manager calibration protocol
I can write anything I like, and leaving server implementors and application writers in the dark about reasonable/expected color management behavior isnât doing anyone any favors.
The whole point of a color management extension is to shine some light into an otherwise ignored behavioral aspect of Wayland, and the current non-color managed behavior is something people are already starting to depend upon.
Maybe. I donât feel that the proâs and conâs of fixing the default as sRGB or allowing it to be configured have been explored sufficiently to come to a conclusion yet. Feel free to put forward your thoughts on the user cases.
Itâs logically impossible to do color management without a description of the display behavior. There may not be any by default.
And a server is perfectly free to populate each display with a default profile created from an EDID if it is available and makes sense. But if such information is not available (i.e. the display doesnât have that kind of interface) or is corrupt (an all too common problem with manufacturer EDID info.), then there will be no default output profile to enable color management unless it is set by a suitable profiling application.
But they can be measured. Or estimated. Or defaulted. Better to have the mechanisms to manage it than throw up ones hands and do nothing. (Chicken and Egg, someone has to start).
Iâm moderately confident they are - the proof will be in the pudding. And no, HDR isnât any harder than other aspects of color management - easier in fact in many ways because it is all about a single dimension of color.
In what way ? âserverâ is short for âWayland serverâ.
Itâs a non-starter for each Wayland implementation to have itâs own API for color management tools to manage the server color configuration, and these are basic facilities provided by every other system. Linux (and similar) are already out on a limb in regard their application interfaces - they are the least popular by far (measured by numbers and usage of applications), and ditching one of the most stable in that world (X11) and creating a new one (Wayland) is fraught enough - further fragmenting by server implementation is a death sentence in my view. [API instability, fragmentation and simple lack are the reason there will never be a âLinux year of the desktopâ.] And no, shoving it off on library writers doesnât solve it - someone still has to do the work, and library writers wonât implement such specialized interfaces as server color management APIâs.
That would be useful feedback though.
The existing proposals are only of the client side. An integrated set of protocols is needed, and they need to co-developed. Trying to get the existing proposals changed in the direction I would like to see doesnât appear to be productive of anyoneâs time. (In retrospect the time and energy I have spent in explaining color management to people interested in Wayland would have been far better spent on simply attempting to implement it.)
Sure you can. The protocol is going nowhere then, though. Itâs simply how specifications work and if you donât comply with it nobody will take it serious.
Their fault then. It something isnât specified it isnât specified.
The rationale is that right now all applications either assume sRGB or are color managed, which is broken on wayland right now. Color managed applications need patches to use the new protocol anyway and therefor do not rely on the default.
If there is anything that speaks against it Iâd like to hear it.
Youâre ignoring the fallback to sRGB. If everything else fails the compositor can simply assign an sRGB profile. Again: where is the advantage of not having a defined output color space?
Specifying something that doesnât work is worse than leaving it unspecified. This isnât a chicken egg problem, what youâre proposing simply doesnât work on current consumer hardware afaict.
From a color theory perspective, sure. From a technical âwe actually have to drive real hardwareâ perspective, not at all. If youâre interested: https://members.cta.tech/ctaPublicationDetails/?id=11016f33-3422-e811-90ce-0003ff528c1a (requires an account but you can use a throwaway).
Naming a protocol something with âserverâ is misleading because every wayland protocol defines the communication between clients and server. No exception.
Welcome to free software. Everyone can do whatever they want, nobody has to implement any specifications or standards or anything. Everyone has slightly different ideas of how things should work. If you want something to become a de-facto standard you have to convince each and every one. Doing so gets harder the more the specification mandates and the bigger it is. Splitting it into independent pieces, iterate on the design to get more people on board and then target the next piece is the only way this can be done.
Your expectations are utterly unrealistic. I canât stop you from going ahead with that approach but it will fail and thatâs a damn waste of time and effort.
I think my track record speaks for itself.
1 Like
Your track record of getting changes into upstream projects like wayland, gnome and kde? Thatâs the problem here, not your ability to work on your own project you control.
Donât you want to to talk about the other points?
Current (consumer) HDR screens contain their own black-box tonemapping and color management, the reason for this is that it simplifies the data stream just sent rec.2020-PQ or HLG and the screen will do the rest. Worse embeded in the stream is extra data (the Infoframes) that tell the screen the intended content brightness levels and the screen is AFAICT allowed to change its tonemapping and color management parameters to show the âbestâ picture possible (so if you change the infoframe data the displayed image might change! Also best is probably defined as looking good to the average consumer not necessarily color accurate).
Currently as far as I can tell there are almost no consumer screens that allow direct access without going trough this black box, the only exception being screens that support Freesync2 HDR (see my previous post with links to gpuopen.com). Funnily enough this was not designed due to color accuracy concern but due to latency concerns so for now only gaming screens will have it.
Ergo without something like Freesync2 HDR support it is nearly impossible to calibrate/profile a HDR screen and I would say a bit of a fools errand. I do suspect that either this part of Freesync2 HDR will become standardized or a similar standard will be released in the near future, the reason for this will be mix media support and productive application support (since the infoframes are part of the mastering information that wonât be available yet in for example Blender model)
HDR has its practical issues, and the issue of the displays themselves doing content sensitive tone mapping is not something that meshes well with high quality color management. But I think for the moment this is out of scope of a V1 color management system. It lands in the bucket of what to do when the display has more than one color mode. In a lot of cases a color mode is a manual user selection, so the user then needs to manually coordinate the config. of the color management to match if they change it. Where it gets interesting is when the color mode is visible to the OS/Display server or even settable by the OS/Display server, since that opens up the possibility of automatically switching color management configuration.
So ideally Iâd imagine a situation in which there was a known set of capabilities and protocols to get a displays color mode and then switch to the corresponding color profile. For SDR modes and HDR modes where the display isnât doing content sensitive processing, this should work well from a color perspective, but any âsmartâ content sensitive tone mapping would have to be performed by applications. If the display is in a tone mapping mode, then the profile will have to be a compromise of some sort, and the results will be variable in terms of color behavior if the display tone mapping is content sensitive.
I have more than enough to do in working on applications, rather than try and write infra-structure as well, and spend the time and effort in each forum playing the pecking order game.
[ Or to put it another way, you are attempting to criticize me for writing software and giving it away for free, but with the caveat that I might be able to scrape a living out of it, rather than spending all my time working on open source projects where I get no financial compensation at all, and have to literately live on nothing! I may be stupid, but Iâm not that stupid - I can work on such open source projects only if Iâm on someones payroll for the purpose (Red Hat, Intel, AMD etc.), or maybe if I had a secure job it would be possible to work on such project in my âspare timeâ. Such is not the situation. That I can allocate a couple of weeks or so to look into developing Wayland color management extensions is the result of a surprising turn of events which I wonât elaborate on. ]
Since you donât appear to value my experience or views, it doesnât seem to be a fruitful use of time. i.e. if you donât âgetâ why an API for color management tools needs to be part of the protocol(s), then there is not much point in trying to converse much further, since we arenât on the same page.
1 Like
And yet in the Television world people do so. I donât expect it is perfect no, and a lot of effort seems to go into tricking the TV into giving a more or less consistent response.
1 Like
Yes this is possible (that is one advantage of HDR it is implemented as a display mode so the compositor can set it and disable it) and wanted but as far as I can tell already possible in the current proposals since nothing really special is needed here (besides the fact to tell the application that the profile changed, but this is wanted as well if a person for example changes the configuration or something else happens that changes)
Any references? And are you sure this is with consumer hardware? I am not supersized that people are trying this (seeing as especially on consumer HW there is little other choice) but I donât think the results will be anything spectacular, for best results you would probably need to intercept the infoframes and set those to a fixed value but still that does mean the screen will do a color management step[1] (not just a tonemapping step, also the tonemapping will probably include a shift to white for extremely bright objects)
All in all I think supporting this use case is a lot of work for little to no gain, so depending on which direction the industry goes we might need to support in the future I would prioritize the direct access HDR over the current designed for (watching/consuming) TV based ones.
[1] most HDR screens are closer to DCI-P3 but the data sent to them is still rec.2020 and TV makers are unconcerned with color accuracy but want something that sells TVs so probably includes some kind of beautifying LUT
Thatâs an opinion you vehemently keep repeating without ever making a good case for it.
Which is the point. You donât do that but you still wonât let people tell you how it works.