The protocols for Wayland have not even been finalized and there isn’t any code for it. Maybe you ran displaycal under xwayland?
How to verify reliably?
Using this method
Launch xeyes and move mouse over a window. If the eyes are moving, it’s an XWayland window, otherwise it’s a native Wayland window.
it seems to me, that displaycal is using wayland. The eyes do not move. They do not move for Firefox either, which I made sure is using wayland. For darktable itself they do move.
Edit: well, could it be that the actual calibration window (i.e. colour patch) uses a different display server? I cannot verify if this is a wayland window too or not since I do not have access to the calibration instrument at the moment. All I can say is that the displaycal main window seems to be using wayland.
If the calibration itself took place using xwayland, what downsides would there be? Whatever it did, it seems to have produced a valid profile.
For some reason DisplayCAL (python-3) wasn’t detecting my i1p3 yesterday when running under sway.
The GUI in displayCAL is wayland native, but colour patch (argyll) is running under XWayland (xeyes test, killing xwayland kills the patch)
Strangely, colormgr get-outputs doesnt return anything, so I dont think that the VCGT is being applied, although maybe I’m using it wrong.
Okay, that’s what I thought. Still not sure what the implications are exactly. So maybe my profile is garbage, even though it looks correct somehow? I don’t have time to investigate further now. Maybe I can try to create a new profile in Windows in the next few days and compare the outputs.
Not knowing what went on exactly and unsure of wether the generated profile is valid or not, I am happy with how things look for now. Before I go on to do some “serious” work, I will investigate further. As I said above, for now things look reasonable the the somewhat greenish tint of my display is gone - just like when I calibrated on Windows.
There is also a open issue on github github which states that VCGTs cannot be (re)set with wayland. Indeed the options are greyed out in displaycal’s GUI. Anyway…more insight is welcome.
1 Like
That its not Wayland. In my own personal experience, the people who advocate for Wayland have been extremely pushy and not very good at listening.
I don’t want a hack stack of xwayland. Wayland doesn’t have a full color management stack yet, thus it isn’t very useful if you’re serious about photo editing.
These are just the facts. Xorg works now and has worked for a while. Is it the future? No. But its certainly the working present.
If that’s OK with you, then go for it. I’ll wait for things to be 100% working. But don’t claim Wayland is ready for this use case. It is not. Any even when it is, there is still quite a bit of software that needs to adapt before the whole stack is ready.
1 Like
I’m not sure if so much bluntness is required. I get it that people keep posting wayland problems when it’s not officially supported by most major photo applications but keeping almost a personal grudge about it doesn’t seem like the way to go… I’ve seen it on other wayland posts too, but never commented.
In the end I’m not sure if we lose more than we gain by having early adopters like this, specially now as wayland is finalizing part of their color management stack. In a way we’ll have a chicken and the egg problem really soon when it comes to photo app developers(and users) being willing to get on wayland so they implement what is required.
2 Likes
running the calibration under xwayland and xorg (openbox) produced the same results.
Of course, the appeal of wayland is not needing to deal a hacky mess like X11, so ideally Xwayland is only temporary.
We need people who simultaneously want to use wayland and want colour management to push change.
“Looks right” is absolutely the wrong way to think about calibration. “Is measureably within the tolerances for accurate color” is much better.
The code says that it can only be set with colord, but I can’t seem to figure out how to get colord to list my outputs.
I’ve personally had too many encounters with the Wayland crew saying its time to leave Xorg and Wayland is ready for my use case. But it isn’t. Is that being too blunt?
Sure when its ready with a full color management stack and the downstream software like DT and rt have worked out the kinks, I’m sure it’ll be great. Wayland has a lot of great features… But its not ready and I have photos to edit now. I’m glad you’ve picked up on my frustrations on being told what I should use on my computer and what my needs for a specific stack are, because, I am, in fact, very frustrated by this.
You can compound this frustration because the Wayland people will start sliding the goalposts backward, “oh um well you can load an ICC profile, that’s good enough.” And if that’s good enough for you, that’s great, go for it.
Keep in mind this has been happening for years. I’m glad that Wayland is getting there now, and I’ll be happy to switch. But that doesn’t erase this frustration.
2 Likes
No, that’s fine and it’s the truth.
I didn’t mean it with ill intention, just that these users in particular might not even be part of the “wayland crowd” and just regular folk who happen to use it, without being apologists (I’ve seen those, maybe not here yet but on other forums). Your frustration is completely valid, specially as a mod/someone who has to provide support often.
I didn’t take it with I’ll intent and didn’t take the other post with I’ll intent either. I hope my frustrations aren’t off putting.
We do need to test when Wayland compositors start landing these features. However, right now they’re adding API to the spec.
1 Like
Well, no offense taken but your “personal frustration” is indeed quite “in the face”. I’ve seen other discussions, too and to be honest, I can understand both “sides” (if there are any…in the end we are in the same boat). But really, fine by me!
I get it that wayland does not support every aspect of proper color managment, eventhough there seems to be progress. For me right now there is no reasonable way to switch to an x-based environment. What I am looking for is dependable information on what works and what does not.
And sure “looks right” is absolutely the wrong way to go about it. That is precisely the reason why I am here and bought an instrument for objection measurement, not merely trusting my eyes.
What I am still unsure of - and maybe someone can speak to this - is if waylands current lack of features impedes my workflow in any way.
-
If I create a proper profile on Windows or maybe an x-based environment and asign/load this profile with colord in wayland, does that apply and properly work in darktable too, even though it uses xwayland?
-
Does soft proofing in darktable work in a setup as described above or not?
-
Am I running (to the best of your knowledge) any risk of getting a useless/wrong profile by doing what I did? I.e. creating a profile on wayland/xwayland and using it with colord?
I am okay with “yes” or “no” or even “don’t know” answers. But these are the question that matter for me personally at the moment. I understand that the situation is not ideal and I understand that there is no “clean” way with wayland at the moment, but I am willing to take detours if the results are reliable. I have no clue, and I do not want to start a wayland vs x-debate. 
I’ve seen lots of posts and lots of discussion but I am none the wiser.
I think part of the rough part of wayland is the number of compositors, so the answer will depend specifically on which compositor you’re using. Generally speaking, wayland should be able to use colord to load an ICC profile and apply it to the screen.
I don’t know if xwayland is also capable of this and I don’t know if darktable or other raw editors are capable or reading that pipeline. One way to test might be to take an ICC profile that swaps some channels and apply it as your display profile. No clue if that’s a valid test, just thinking out loud.
For 2 & 3, I don’t know.
1 Like
Thanks! Thats helpful. Maybe someone or myself gets around to test this. Not today, not tomorrow but it is a starting point. 
Edit: more insight on github! It seems vital to make sure to work on “clean” gamma tables as the github comment suggests. Other than that, things seem to work more or less when it comes to profile creation and setup. That is not to imply that everythings works as intended with DT. Anyway, useful info.
1 Like
You might be able to use the web @ localhost option in DisplayCAL, using firefox (color managed) with and without xwayland then compare results.
an “eye test” of switching back and forth between TTYs running the same software under wayland and under X might help detect obvious issues
2 Likes
I’m on Fedora 38 KDE. I use x11 and color management works.
Every once in a while I try Wayland to test if it works. It still doesnt work. Until they merge upstream I see no reason to hack a way to make Wayland work when X11 is working.
FYI, soft proofing works for me on dt.
2 Likes
I dont see how “I use x11 and see no reason to switch to wayland” is helpful for wayland specific questions. Thanks for all the other feedback though. Some nice suggestsions, helpful replies on github. Seems like calibration and color management can be achieved if you are careful and know what to watch out for. I guess thats my way then until things improve and get more streamlined/implemented in the first place.
I tested DisplayCAL again today on Fedora 38 under Wayland. DisplayCAL 3.8.9. runs under Wayland and it does show the colourpatches to calibrate.
The moment is goes wrong is when it tries to install the profile at the end of the calibration cycle.
I got a error message:
“The profile could not be installed/activated.
ArgyllCMS: Dispwin: Error - We don’t have access to the VideoLUT for clearing”
DisplayCAL does seems to create a profile, stored under
/home//.var/app/net.displaycal.DisplayCAL/data/DisplayCAL/storage/
but when I try to install the profile in the KDE Colour Management settings of my Display I can not assign the icc profile. The “Assign Profile” button doesn’t seem to work.
Under X this works.
1 Like
As we collectively figured out, the actual color patches are displayed via xwayland. And as well explained in github comment 1 and github comment 2 displaycal and more specifically argyll cannot access the video card gamma tables, eventhough they “assume” they can. So you really have to make sure you calibrate from a clean slate. I don’t know the state of things in KDE but the gnome-UI does not seem to work reliably when it comes to assigning/enabling profiles. This is also mentioned in the comments.
That being said, the error message is reasonable. Have you tried the latest version of displaycal? It was forked ages ago to support Python 3 and since then, development went on. You can get it from here for example.
I have no clue what KDE uses to install/manage ICC-profiles but if its colord, too by default, you can follow the guidance in the github comments or take a look at the excellent Arch-wiki. There are tips and explanations for other programs too if you prefer/use any of those.
1 Like