enable wayland

[christianrauch]

This enables Wayland with X11 fallback.

[flathubbot]

Started test build 72186

[flathubbot]

Build 72186 failed

[flathubbot]

Started test build 72187

[flathubbot]

Build 72187 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/70037/org.darktable.Darktable.flatpakref

[paperdigits]

Wayland is still a compromise because there is not working color management yet.

On December 24, 2021 5:15:23 PM PST, Christian Rauch @.***> wrote:

This enables Wayland with X11 fallback. You can view, comment on, or merge this pull request online at:

https://github.com/flathub/org.darktable.Darktable/pull/82

-- Commit Summary --

• enable wayland

-- File Changes --

M org.darktable.Darktable.json (3)

-- Patch Links --

https://github.com/flathub/org.darktable.Darktable/pull/82.patch https://github.com/flathub/org.darktable.Darktable/pull/82.diff

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[flathubbot]

Started test build 72213

[christianrauch]

Wayland is still a compromise ...

What do you mean by "compromise"? A compromise between what?

... because there is not working color management yet.

Is this required for darktable? Can you point to an example of what functionality would be missing when running as a Wayland client and what would be available under XWayland?

[flathubbot]

Build 72213 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/70063/org.darktable.Darktable.flatpakref

[paperdigits]

By "a compromise" I mean "not working to it's full potential".

If you're running g Wayland, you won't have a color managed environment for darktable, which means you can run a calibrated monitor, which i consider eassential.

On December 25, 2021 4:48:23 AM PST, Christian Rauch @.***> wrote:

Wayland is still a compromise ...

What do you mean by "compromise"? A compromise between what?

... because there is not working color management yet.

Is this required for darktable? Can you point to an example of what functionality would be missing when running as a Wayland client and what would be available under XWayland?

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1001013523 You are receiving this because you commented.

Message ID: @.***>

[christianrauch]

But will colour management work, if I run darktable via XWayland? If this is not the case, then it does not matter how someone runs darktable in a Wayland compositor - colour management will not be available anyway.

[paperdigits]

I don't think that using xwayland will work, as Wayland is still involved, so no color management.

On December 25, 2021 9:02:24 AM PST, Christian Rauch @.***> wrote:

But will colour management work, if I run darktable via XWayland? If this is not the case, then it does not matter how someone runs darktable in a Wayland compositor - colour management will not be available anyway.

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1001045219 You are receiving this because you commented.

Message ID: @.***>

[christianrauch]

Right. I think this solely depends on the compositor. The point I want to make is that the available set of functions is not reduced by merging this "native Wayland" support. Colour management won't work either way and it does not matter if you run the current flatpak on Wayland via XWayland or if you run a native Wayland client by merging this.

[paperdigits]

Yes, this is an X11 vs Wayland thing, not a Wayland compositor vs another Wayland compositor thing.

X = feature complete for purposes of color management.

Wayland = not suitable for editing IMHO

On December 25, 2021 9:11:59 AM PST, Christian Rauch @.***> wrote:

Right. I think this solely depends on the compositor. The point I want to make is that the available set of functions is not reduced by merging this "native Wayland" support. Colour management won't work either way and it does not matter if you run the current flatpak on Wayland via XWayland or if you run a native Wayland client by merging this.

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1001046250 You are receiving this because you commented.

Message ID: @.***>

[christianrauch]

I understand the limitations of colour management on Wayland.

But those also exist on XWayland. So the argument of not enabling the Wayland client because of colour management does not count because this problem already exists when using darktable via XWayland.

With this PR, darktable will still use X11 with colour management on an X.org desktop.

Are there other limitations or issues why you don't want to merge Wayland support?

[paperdigits]

Well I don't have permission to merge, just pointing out that using Wayland at all is problematic for an application such as darktable.

On December 25, 2021 12:41:19 PM PST, Christian Rauch @.***> wrote:

I understand the limitations of colour management on Wayland.

But those also exist on XWayland. So the argument of not enabling the Wayland client because of colour management does not count because this problem already exists when using darktable via XWayland.

With this PR, darktable will still use X11 with colour management on an X.org desktop.

Are there other limitations or issues why you don't want to merge Wayland support?

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1001070834 You are receiving this because you commented.

Message ID: @.***>

[matze]

I do have merge rights but last time I tried running Darktable as a Wayland client I had some UI issues but not sure what the status is more than a year later. Out of curiosity, does the Flatpak option automatically set the GDK_BACKEND variable or is that not required anymore?

[hfiguiere]

By default the behaviour of Gtk is to try to connect to wayland and if it can't to connect to X11, Unless the backend is set. So playing with the sockets is all that is needed.

[matze]

So, let's give this a go?

[snaggen]

Notice that darktable doesn't use GDK default behaviour regarding wayland. In common/darktable.c there is this code

  #ifdef GDK_WINDOWING_WAYLAND
      // There are currently bad interactions with Wayland (drop-downs  
      // are very narrow, scroll events lost). Until this is fixed, give
      // priority to the XWayland backend for Wayland users.
      gdk_set_allowed_backends("x11,*");
  #endif

that will prevent wayland from being used. So to enable wayland support you would have to create a patch to remove this.

[snaggen]

Also regarding wayland and color profiles, I'm under the impression that using color profiles are actually supported in some way under wayland, but it was calibration that was not supported. I think I remember someone saying that you can login to your X11 desktop and calibrate the screen, and then go back to your wayland environment and it will use the calibrated profiles. But, this was a while ago, so things might have changed, or I can remember it incorrectly.

[hfiguiere]

A patch for this is a no-no. This is an upstream matter.

[christianrauch]

Notice that darktable doesn't use GDK default behaviour regarding wayland.

If you read the documentation for gdk_set_allowed_backends on https://docs.gtk.org/gdk4/func.set_allowed_backends.html, you will see that this just defines the order in which GDK backends are tried. In this particular case, this just means that it will try to use x11 first and then all others, including Wayland. I don't think it is necessary to change this.

As far as I can tell, enabling Wayland via Flatseal (com.github.tchx84.Flatseal) by setting the socket=wayland switch, starts darktable as Wayland client. You can easily verify this on GNOME through looking glass or via xeyes. Setting socket=wayland is all that is required to start darktable as Wayland client. No need to patch the source manually.

[nalsai]

I can confirm that enabling Wayland via Flatseal works, including the titlebar and resizing. There is no patch needed.

Regarding color management, I calibrated my screen using DisplayCAL and added and enabled the color profile in gnome settings (all under wayland). I believe this applies the profile to the whole screen, without communicating with the apps, as the color management protocol for wayland still isn't finished. So everything looks decent but not perfect.

Using wayland darktable-cmstest (flatpak run --command=darktable-cmstest org.darktable.Darktable) shows

Authorization required, but no authorization protocol specified

can't open display `:0.0'

Using xwayland it shows

    colord: "(none)"
        description: (file not found)

The profile isn't used by darktable either way.

There is no disadvantage to using native wayland instead of xwayland on a wayland compositor, I could find, and for me native wayland has the advantage of nice crisp fractional scaling.

[flathubbot]

Started test build 13568

[flathubbot]

Build 13568 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/125998/org.darktable.Darktable.flatpakref

[paperdigits]

I spoke to several developers about wayland support, and they all say "no thankyou, not yet" so know that should this get enabled, you'll likely be on your own, nobody wants to support wayland yet.

[christianrauch]

I spoke to several developers about wayland support, and they all say "no thankyou, not yet" so know that should this get enabled, you'll likely be on your own, nobody wants to support wayland yet.

Can you elaborate on that statement? As it stands, it sounds a bit ridiculous. Which developers? Who does not want to support Wayland? The Flatpak developers clearly want to support Wayland and so do all the larger desktops such as GNOME Shell and KDE Plasma. Also, many toolkits support Wayland now. The major Linux distributions use Wayland by default now. Is "nobody wants to support wayland yet" just your personal preference?

As I understand from https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1364594416, Darktable does not use colour profiles either way. So what would be the disadvantage of supporting Wayland?

[paperdigits]

Can you elaborate on that statement? As it stands, it sounds a bit ridiculous. Which developers? Who does not want to support Wayland?

The darktable developers, including the maintainer. You can see and/or ask for yourself in the "darktable management" matrix room or email the dev mailing list.

Is "nobody wants to support wayland yet" just your personal preference?

It is extremely insulting to suggest that I would lie to push my personal preference. Please think about what you say before you actually say it. I don't have a personal preference here. If wayland was fit for darktable's purpose, then this would be a different story.

Please also consider that wayland is not suitable for an application such as darktable. There is no color management yet, a key feature for darktable. So far as I'm aware, none of the main developers use wayland, so there is no testing against wayland.

In my own personal experiences supporting darktable, I've already encountered a few bug reports from users where "go back to X11" has solved the issue.

I'm sure wayland is the future, but it just isn't the present. That's not a personal preference or opinion, but the fact of the lack of features wayland has at present.

[christianrauch]

It is extremely insulting to suggest that I would lie to push my personal preference. Please think about what you say before you actually say it. I don't have a personal preference here. If wayland was fit for darktable's purpose, then this would be a different story.

I am not insulting you. You are publishing generic statements without backing them up with evidence. Saying something like "nobody wants to support wayland yet" is just plain wrong given the work on this by multiple desktops and toolkits. You did not specify that this "nobody" only applies to the small subset of Darktable developers. I was just asking if rejecting Wayland support is a personal preference of you. You could have your (valid) reasons, e.g. you may not have a newer system with Wayland support. I was just asking and not stating that this is your personal preference.

Please also consider that wayland is not suitable for an application such as darktable. There is no color management yet, a key feature for darktable. So far as I'm aware, none of the main developers use wayland, so there is no testing against wayland.

I acknowledge that there is no colour management on Wayland yet. But can you please respond to the comment https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1364594416 about colour management on XWayland? Does flatpak run --command=darktable-cmstest org.darktable.Darktable show something else than colord: "(none)" on your system with XWayland? Are you certain that colord is actually supported and used on XWayland? If not, I don't see the disadvantage of enabling Wayland.

[lnicola]

@christianrauch from what I've seen of the DT developers (making fun of users who don't understand something or calling outside contributors stupid when they didn't agree with them), they're not really open to ideas they don't like. Unfair generalizations aside, you can probably expect them to be completely against making life easier for Wayland users as long as they're not using it themselves.

[paperdigits]

I am not insulting you.

Sorry, it doesn't work like this. When you say something offensive, you don't get to decide if someone is offended by it or not. Please have some decorum.

You did not specify that this "nobody" only applies to the small subset of Darktable developers.

It is the darktable team, and that is the application we're talking about here; context is important.

I was just asking if rejecting Wayland support is a personal preference of you.

It isn't, and I've made that clear. Again, for you to persist is rude. Please stop.

I acknowledge that there is no colour management on Wayland yet.

So wayland is ready for darktable yet, just like it isn't ready for blender or krita or kdenlive or any other application where color is an important feature.

But can you please respond to the comment https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1364594416 about colour management on XWayland? Does flatpak run --command=darktable-cmstest org.darktable.Darktable show something else than colord: "(none)" on your system with XWayland? Are you certain that colord is actually supported and used on XWayland?

Again, wayland, and that includes xwayland which is running on top of wayland, is not suitable. If you want the best, most tested, and feature-rich darktable, then you need to use X11.

If not, I don't see the disadvantage of enabling Wayland.

xwayland is still wayland. The disadvantage of both is that darktable is not currently tested on these, and nobody is interested in testing and writing code to fix bugs yet. Once wayland has working color management and we can run argyll CMS or displaycal, profile our displays, and have the colord and/or xatom parts working, I'm sure we'll jump on it. But, again, that time is not now. That is what I meant by "you'll be on your own."

making fun of users who don't understand something or calling outside contributors stupid when they didn't agree with them), they're not really open to ideas they don't like.

That dev is toxic, is no longer contributing because of his behavior, and has hard forked darktable. If we wrote off every project that had one bad apple, we wouldn't have much to use.

[lnicola]

Once wayland has working color management and we can run argyll CMS or displaycal, profile our displays, and have the colord and/or xatom parts working, I'm sure we'll jump on it.

It might not be obvious, but color management works just fine in GNOME Wayland, including screen calibration. It might work on KDE too, I don't know.

That dev is toxic, is no longer contributing because of his behavior, and has hard forked darktable. If we wrote off every project that had one bad apple, we wouldn't have much to use.

I know who you're talking about and how the fork, but didn't realize they're no longer contributing to Darktable. I'm not sure it was the only person acting like this, but I'll take your word for it that the project is more welcoming now.

[paperdigits]

Please elaborate on working color management in Wayland GNOME.

On December 28, 2022 12:46:56 PM PST, "Laurențiu Nicola" @.***> wrote:

Once wayland has working color management and we can run argyll CMS or displaycal, profile our displays, and have the colord and/or xatom parts working, I'm sure we'll jump on it.

It might not be obvious, but color management works just fine in GNOME Wayland, including screen calibration.

That dev is toxic, is no longer contributing because of his behavior, and has hard forked darktable. If we wrote off every project that had one bad apple, we wouldn't have much to use.

I know who you're talking about and how the fork, but didn't realize they're no longer contributing to Darktable. I'm not sure it was the only person acting like this, but I'll take your word for it that the project is more welcoming now.

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1366907586 You are receiving this because you commented.

Message ID: @.***>

[lnicola]

I got a screen calibrator two years ago, used it with displaycal to create a profile for my screen (under Xorg, because I didn't expect it to work under Wayland), then logged in to Wayland by mistake and noticed my profile was still there. I can still run displaycal and notice no difference between Xorg and Wayland sessions. Note that I'm still a beginner at this stuff though, so I might be missing something really important.

If you want proof, I can record a video of me switching profiles tomorrow.

[paperdigits]

By "I can still run displaycal" you mean you can run it under full Wayland, generate new profile, load that profile and have some color aware application use that profile?

On December 28, 2022 1:48:25 PM PST, "Laurențiu Nicola" @.***> wrote:

I got a screen calibrator two years ago, used it with displaycal to create a profile for my screen (under Xorg, because I didn't expect it to work under Wayland), then logged in to Wayland by mistake and noticed my profile was still there. I can still run displaycal and notice no difference between Xorg and Wayland sessions.

If you want proof, I can record a video of me switching profiles tomorrow.

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1366932867 You are receiving this because you commented.

Message ID: @.***>

[lnicola]

I created a profile and applied it to the monitor in GNOME Settings, and noticed the colors changing when switching between the monitor's EDID profile and the one I made. I can check tomorrow if Wayland-native and Xwayland apps respond differently to it.

I don't know about the color management-aware programs. As I said, I only know some of the basics, but I think most of them care about e.g. a printer or paper profile, which I don't have. I don't know if they use the monitor's profile.

[paperdigits]

From what I know now, loading a profile and having the monitor use it works, but calibrating using displaycal + hardware doesn't work, nor does colord talking to color-managed applications and to Wayland.

On December 28, 2022 3:18:27 PM PST, "Laurențiu Nicola" @.***> wrote:

I created a profile and applied it to the monitor in GNOME Settings, and noticed the colors changing when switching between the monitor's EDID profile and the one I made. I can check tomorrow if Wayland-native and Xwayland apps respond differently to it.

I don't know about the color management-aware programs. As I said, I only know some of the basics, but I think most of them care about e.g. a printer or paper profile, which I don't have. I don't know if they use the monitor's profile.

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1366977081 You are receiving this because you commented.

Message ID: @.***>

[christianrauch]

So wayland is ready for darktable yet, just like it isn't ready for blender or krita or kdenlive or any other application where color is an important feature.

Why is Wayland not ready for Blender? Do you have evidence? How does it come that the Blender developers have a different opinion on this?

Again, wayland, and that includes xwayland which is running on top of wayland, is not suitable. If you want the best, most tested, and feature-rich darktable, then you need to use X11.

You talked about colour management before, but the test with darktable-cmstest suggests that this is not available on XWayland anyway. This PR does not change the behaviour when running on X11 and it does not reduce the feature set when running on Wayland. Can you please be specific about which feature you are loosing by applying this PR?

[paperdigits]

Why is Wayland not ready for Blender? Do you have evidence? How does it come that the Blender developers have a different opinion on this?

If you read the article you linked, the blender developers are saying pretty much the same thing I am "Long term, native Wayland support should give us the best user experience" [emphasis mine] -- which means "in the future, not the present.

It is also really disingenuous to try and pass off your own contributions as the current outlook of blender. The wayland support is in beta which means it is not ready.

Blender is not ready for wayland because they too need color management, which wayland currently lacks a fully working stack. Maybe if the wayland developers had spent more time listening some 3 years ago then things might be better, but then again, maybe not. I don't know.

This PR does not change the behaviour when running on X11 and it does not reduce the feature set when running on Wayland. Can you please be specific about which feature you are loosing by applying this PR?

Because upstream (darktable) is not ready nor equipped to support wayland. Wayland is not feature complete in terms of supporting darktable. By enabling wayland support, we'd be implicitly signaling that (1) wayland has all the necessary features to support darktable and (2) that darktable is ready to support use on wayland. Neither of these are true, hence why I, a person who does a lot of support for the darktable application, do not want to enable it.

I've been sold on flatpak as means for distribution because end users can get software packaged as the upstream project wishes.

[christianrauch]

It is also really disingenuous to try and pass off your own contributions as the current outlook of blender.

Why is that? Do you really think it is disingenuous to mention that Blender uses Wayland by default now, just because I contributed up to the point where it is deemed stable by the main developer? I put a lot of effort into bringing Blender to this state and I am actually proud of this.

Why do you accuse me of insulting you, call me rude and now diminish my contributions to Blender? This started as a technical discussion and now you are calling me names. Why would I insult you when trying to get this PR merged? This makes no sense. I never used hard words against you but now this conversation derails. I am not happy with how this goes. Can we please get back to the technical discussion?

The wayland support is in beta which means it is not ready.

Where does it say Blender's Wayland support is in beta state and not ready?

Blender is not ready for wayland because they too need color management, which wayland currently lacks a fully working stack.

As we already argued, colour management on XWayland also does not seem to work, unless you can show that Darktable or Blender can use colour management on XWayland and not on native Wayland. Why are you repeating this argument?

Maybe if the wayland developers had spent more time listening some 3 years ago then things might be better, but then again, maybe not. I don't know.

This is not really the topic here. What are you trying to achieve with this argument?

Because upstream (darktable) is not ready nor equipped to support wayland. Wayland is not feature complete in terms of supporting darktable. By enabling wayland support, we'd be implicitly signaling that (1) wayland has all the necessary features to support darktable and (2) that darktable is ready to support use on wayland. Neither of these are true, hence why I, a person who does a lot of support for the darktable application, do not want to enable it.

I accept the argument that you would signal that all features are supported, which is not the case at the moment. But you have no control over how users run the Darktable flatpak. If they run it on a default installation of any recent Linux distribution, the Darktable flatpak will run via XWayland anyway.

[paperdigits]

Why is that? Do you really think it is disingenuous to mention that Blender uses Wayland by default now,

Oh I see, you've linked to an article that is outdated. Please link up-to-date resources if you're trying to make an argument next time.

Why do you accuse me of insulting you

Again, this isn't how it works. You don't get to say something insulting then decide who is or is not insulted by it. You've insulted me, you've offered no remorse or apology, and that is in fact rude. That you only double down on your position on furthers this matter.

Why would I insult you when trying to get this PR merged? This makes no sense

I agree.

I never used hard words against you but now this conversation derails.

I disagree, it derailed when you began being insulting. The doubling down on that position along with the lack of effort on understand the position of the upstream project really leaves a bad taste here.

Where does it say Blender's Wayland support is in beta state and not ready?

In the article you linked. I realize that its out of date now.

This is not really the topic here. What are you trying to achieve with this argument?

That much like that thread, you should listen to what is being said here. Upstream does not want to support wayland yet, it is not feature ready for darktable.

As we already argued, colour management on XWayland also does not seem to work, unless you can show that Darktable or Blender can use colour management on XWayland and not on native Wayland. Why are you repeating this argument?

I don't need to show that color management doesn't work on xwayland, I already know that. So do you. Neither xwayland nor wayland are ready. People who want to use darktable in best and most tested state should use X11.

Why should we enable something that doesn't work correctly and isn't supported by upstream?

But you have no control over how users run the Darktable flatpak.

So should we abandon all standards because we have no control? Honestly this is a terrible argument.

If they run it on a default installation of any recent Linux distribution, the Darktable flatpak will run via XWayland anyway.

Good for them. And when they come to the places where darktable offers support, they'll be told to use X11. Is it a good user experince to enable wayland, then when there is issues to tell them that it isn't supported by the darktable project and advise them to use X11? That is what you're proposing.

Again, if you want to use wayland or xwayland, that is fine. But you're on your own for support. Enabling it here makes no sense. Flatpak is about upstream packaging the software how the upstream project sees fit.

[christianrauch]

Oh I see, you've linked to an article that is outdated. Please link up-to-date resources if you're trying to make an argument next time.

Would you be so kind and link that up-to-date resource?

Again, this isn't how it works. You don't get to say something insulting then decide who is or is not insulted by it. You've insulted me, you've offered no remorse or apology, and that is in fact rude. That you only double down on your position on furthers this matter.

I was only asking if your statement "nobody wants to support wayland yet" is your personal opinion or if you have evidence to back this up. At that time, it was not clear to me that this only referred to the Darktable developers.

If this is really "extremely insulting" to you, then I am sorry for having asked this question. It was not my intention to insult you.

Your initial argument was about colour management and I just wanted to make the case that colour management will not work on Wayland compositors either way. Nothing more. Since then, you changed your argument against enabling Wayland support.

[paperdigits]

Would you be so kind and link that up-to-date resource?

Strangely I didn't find the mentions of wayland enablement in blender's own release notes, but the linux blogs thought it was important: https://9to5linux.com/blender-3-4-released-with-native-wayland-support-on-linux-many-improvements

Note that the thing you linked, at the very top says "Wayland is now enabled for daily builds and if all goes well, it will be enabled for Blender 3.4 release too." -- which is future tense for wayland being enabled. Not clear you actually read what you linked.

Since then, you changed your argument against enabling Wayland support.

I have not. My argument the whole time has been "wayland is not ready for an application such as darktable because it doesn't have color management."

If you and @hfiguiere want to support wayland for darktable, go for it, and please let me know where to send people for support with wayland. The answer from darktable is "Use X11 for the best results."

[christianrauch]

Strangely I didn't find the mentions of wayland enablement in blender's own release notes, but the linux blogs thought it was important: https://9to5linux.com/blender-3-4-released-with-native-wayland-support-on-linux-many-improvements

Are you serious now? You are accusing me of not using up-to-date resources and you now link 9to5linux.com as a secondary source? Do you by any chance mean the 3.4 release notes which mentions this under Platform-Specific Changes?

Note that the thing you linked, at the very top says "Wayland is now enabled for daily builds and if all goes well, it will be enabled for Blender 3.4 release too." -- which is future tense for wayland being enabled. Not clear you actually read what you linked.

Really? You now know that I implemented that and you still think that I am not aware if this got enabled or not?

It appears to me that you do not really want to argue on a technical level. You are stating things in this PR without backing them up with evidence and on the contrary accusing me of misleading you by using outdated evidence. On top of that, you accused me of "extremely insulting" you, being rude and being "really disingenuous". I only asked if your statement "nobody wants to support wayland yet" was your personal opinion or not -- not something that I would be offended about, but I can accept that you are offended -- and backed my statements about Blender up with evidence in order to get this discussion going on a technical level.

If you are offended by me asking a question about your potential personal motivation, then I am offended now by your accusations. Great. I think we can stop the discussion here.

[paperdigits]

You are accusing me of not using up-to-date resources

Not accusing, that page is out of date. You linked to it. I don't follow blender, so I don't know what they're doing. You linked to an out of date page as proof, which lead me to do more searching to see what you were talking about. I spent about 30 seconds googling, and 9 to 5 linux is the second result. Are they wrong? No.

It appears to me that you do not really want to argue on a technical level

There is no argument, just facts: wayland doesn't have working color management, and thus is not suitable for use with darktable. How many times does that need to be said?

You are stating things in this PR without backing them up with evidence

I've told you where you can find the sources for the statements I've made. You can find those above.

If you are offended by me asking a question about your potential personal motivation, then I am offended now by your accusations

This is an absurd position.

[lnicola]

So wayland is ready for darktable yet, just like it isn't ready for blender or krita or kdenlive or any other application where color is an important feature.

I don't follow blender, so I don't know what they're doing.

Note that the thing you linked, at the very top says "Wayland is now enabled for daily builds and if all goes well, it will be enabled for Blender 3.4 release too." -- which is future tense for wayland being enabled. Not clear you actually read what you linked.

Since Blender 3.4 is out, and Kdenlive uses Wayland just fine when asked nicely, are you now willing to reconsider your opinion on whether Wayland is ready or not? The Blender and Kdenlive developers seem to disagree with you.

And when they come to the places where darktable offers support, they'll be told to use X11.

So if Xwayland is just as bad for DT as running natively on Wayland, why go out of your way to prevent users from running it natively? If they ask for help your answer will be the same anyway so you won't care, and at least there's the chance they actually find that Wayland works for them.

From what I know now, loading a profile and having the monitor use it works, but calibrating using displaycal + hardware doesn't work

I've calibrated my screen with DisplayCAL and SpyderX, so one of us must be wrong.

nor does colord talking to color-managed applications and to Wayland.

Can you please describe a test case showing how color management works in DT under Xorg (or better, Xwayland, because the Flatpak doesn't get to choose how it's running, and this is what this PR is all about), and is broken under Wayland? @christianrauch asked about this this, but you've been dodging his question. I'm willing to test it myself, so you don't have to run Wayland.

[paperdigits]

Since Blender 3.4 is out, and Kdenlive uses Wayland just fine when asked nicely, are you now willing to reconsider your opinion on whether Wayland is ready or not? The Blender and Kdenlive developers seem to disagree with you.

Again, "launches on wayland" is not the same as "full working color management" which is the bar for darktable. According to the both of you, darktable also launches with wayand just find with the patch, but that is not good enough in the case of darktable, according to the maintainer of darktable. If you want to use color-critical applications in a non-color managed environment, then... go for it? You can force the wayland socket on via the cli, or you can set the rule using flatseal.

So if Xwayland is just as bad for DT as running natively on Wayland, why go out of your way to prevent users from running it natively? If they ask for help your answer will be the same anyway so you won't care, and at least there's the chance they actually find that Wayland works for them.

I've already answered this, and @christianrauch actually agreed that merging this would signal that darktable work on wayland, which is not true. I've also already covered "but you can't control how the flatpak is run" which is a horrible argument. As a project, darktable makes recommendations on its best use. Flatpak is/was sold as being able to get the software from the upstream project, packaged the way upsteam wants it packaged. What am I missing?

Can you please describe a test case showing how color management works in DT under Xorg

Here is the flatpak under xwayland, as it is released now:

% flatpak run --command=darktable-cmstest org.darktable.Darktable
darktable-cmstest version 4.2.0
this executable was built with colord support enabled
darktable itself was built with colord support enabled

primary CRTC is at CRTC 0

XWAYLAND0       the X atom and colord returned the same profile
        X atom: _ICC_PROFILE (0 bytes)
                description: (none)
        colord: "(none)"
                description: (file not found)

Better check your system setup
 - some monitors lacked a profile
You may experience inconsistent color rendition between color managed applications

Under xorg, it finds the profiles and the profiles match.

or better, Xwayland, because the Flatpak doesn't get to choose how it's running, and this is what this PR is all about

and as I have already said, xwayland = wayland. The best, most tested choice for darktable is X11 for now. We already have enough work trying to support the application under X11, and we don't need more issues from wayland, which none of the developers run and none of the developers are prepared to fix the application at this time.

This could all be ended by pointing to the wayland release notes that say "YES COLOR MANAGEMENT WORKS!" -- it seems like a big feature I'd have heard about, but I can't seem to find it. I'd be happy to be wrong.

[snaggen]

X11 under wayland:

• No proper color management
• Cannot handle multiple screens with mixed DPI

Native wayland:

• No proper color management
• Can handle mixed DPI

So X11 under wayland is a worse user experience than native wayland, and will not provide any advantages regarding color management.

[haplo]

I just saw this article about KDE supporting color profiles in Wayland soon: https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr-and-colormanagement-in-plasma.html

I don't know about the details, but maybe the Wayland policy regarding color profiles has improved? Many Linux distributions will be switching to Wayland in 2024, would be great to make progress towards a Wayland-native implementation without XWayland.

[paperdigits]

Loading an ICC profile is still only half of what is required for an application like darktable. We still need to be able to run calibration software and generate an ICC profile for the monitor; and those things don't even have a finalized protocol yet.

There aren't any plans to start working on Wayland support yet; we want fully working color management.

If accurate color is important to you, pick a distro that still supports X11.

I'm sure the flatpak will enable Wayland support once darktable actually supports Wayland, but that's still a ways off from what I can see.

On December 19, 2023 2:58:07 AM PST, Fidel Ramos @.***> wrote:

I just saw this article about KDE supporting color profiles in Wayland soon: https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr-and-colormanagement-in-plasma.html

I don't know about the details, but maybe the Wayland policy regarding color profiles has improved? Many Linux distributions will be switching to Wayland in 2024, would be great to make progress towards a Wayland-native implementation without XWayland.

-- Reply to this email directly or view it on GitHub: https://github.com/flathub/org.darktable.Darktable/pull/82#issuecomment-1862545384 You are receiving this because you commented.

Message ID: @.***>