Fix Wayland session.

[TurboGit]

Now that GNOME 49 is out and that most distributions are removing support for X11 use the standard Wayland session. The XWayland seems to make Darktable non working (no events, freeze...).

Closes #19511
Closes #19441

[TurboGit]

Please Wayland users do test this PR. I have migrated this morning to GNOME 49 & Wayland session. Without this fix my Darktable was fully broken (no menu, no events...). With this patch it seems to be working correctly.

[rgr59]

Tested this PR and it behaves as master when called with "GDK_BACKEND=wayland ./darktable". I used this for some days after upgrading to Fedora 43, because without it master would only work for some GUI actions and then freeze.

Observations:

• The window frame looks a little different, but not a problem.
• I use a laptop with a connected EIZO screen (something like AdobeRGB color space). darktable does not determine the display profile correctly if "system profile" is configured, but renders as if the profile was sRGB. If I configure the correct display icc profile for the EIZO in darktable (the same that is configured in the Gnome settings), the rendering is OK.

Maybe darktable doesn't get informed that it's window is on the EIZO monitor? The laptop display could well be sRGB. BTW the output of darktable-cmstest looks exactly like in the X11 days, for the EIZO the correct profile is indicated.

Other than this, I did not stumble over misfunctions until now. Not a comprehensive test of course.

[jenshannoschwalm]

No problems with this PR on non-opencl fedora 43 on master.

[TurboGit]

• I use a laptop with a connected EIZO screen (something like AdobeRGB color space). darktable does not determine the display profile correctly if "system profile" is configured, but renders as if the profile was sRGB. If I configure the correct display icc profile for the EIZO in darktable (the same that is configured in the Gnome settings), the rendering is OK.

I think that's expected, we need some new code to get the profile on a Wayland session.

[TurboGit]

So let's move forward. Not sure we will be ready for color management on Wayland for 5.4.

[gi-man]

Fedora KDE still works after this merge. Each compositor (eg. mutter, Kwin) implements Wayland differently, so we need to test the most common ones.

[piratenpanda]

sub menus in presets are gone for me now, they just remove the whole popup. Arch, Gnome, latest updates, latest git for me. Single monitor.

I reverted the patch and everything is back to normal. I also checked if dt is running under xwayland which does not see to be the case:

WAYLAND_DISPLAY=wayland-0
GNOME_SETUP_DISPLAY=:1
DISPLAY=:0
WAYLAND_DISPLAY=wayland-0

[TurboGit]

@dterrahe : Maybe you have an idea at what is going wrong with presets sub-menu? Under Wayland as soon as you fly over it, instead of opening the sub-menu the whole popup is closed. If you have some hint at what to look let me know, I can test. TIA.

[dterrahe]

I can't reproduce this exactly under WSL2 (which uses a forked wayland compositor) but I do have the submenu falls off the right side of the screen problem. We use completely standard gtk3 functionality to have it manage (sub)menu behavior so this is a bug (or at least some wayland related issue not fixed/corrected for) in gtk3. It may be possible to find workarounds, but @zisoft is currently looking into how to reimplement popupmenus for gtk4 which he may be planning on backporting to gtk3 first. #19448 (comment) I'm not sure since I haven't seen his approach yet. There is a chance that that way of handling popup menus is better supported by the gtk3 team and might even work correctly with wayland.

[zisoft]

@zisoft is currently looking into how to reimplement popupmenus for gtk4 which he may be planning on backporting to gtk3 first.

Yes, coming soon. I have found a way which works both in gtk3 and gtk4. I am just making some final refinements and will provide a first PR for gtk3 in the next days, so we can review.

[TurboGit]

@dterrahe @zisoft : Thanks for the feedback. I'll check as soon as a PR is in place on my side. My feeling is that we really want this to be fixed for 5.4 as Wayland is being deployed in many main distributions.

[dterrahe]

I'm just a bit surprised that distributions now apparently decide it is fine to break Xwayland. I thought that would be supported for a while.

[TurboGit]

Maybe they have not broken Xwayland, maybe a specific issue with Darktable. In all cases we have to do the move. I'm now working on supporting color profile without that Darktable is just unusable for serious work. If no solution found we may have to delay the 5.4 release. We'll see.

[TurboGit]

@rgr59 : Can you test #19646 which fixes support ICC on Wayland? It works on my side...

[rgr59]

Please see my comment in #19646

[jenshannoschwalm]

Just mentioning, selecting the dt image border - to enlarge for example - now seems to be more difficult to hit.