dialogs (preferences, shift-copy, etc.) cannot be interacted with most of the time in GNOME on Wayland with more than 1 monitor

[garrett]

Describe the bug

In darktable 4.6.0 (the latest version of darkable available on Linux as a package, aside from Flathub, which has 4.6.1), dialogs are frozen more often than not. This includes preferences from the lighttable and shift-copy from both lighttable and darkroom.

If I keep trying by closing and re-opening the dialog, it will sometimes work, allowing me to change preferences, copy individual or all settings, etc., so it seems like a race condition.

Steps to reproduce

1. Use GNOME on Wayland (this is the default for Fedora Workstation and Silverblue).
2. Have more than 1 monitor.
3. Have "Attach Modal Dialogs" turned on in GNOME (this is the default for GNOME, with no official way to change it).
4. Run darktable, and notice that most of the time, dialogs do not work. However, they do still work sometimes! You can either:
   1. Open preferences or
   2. Press control-shift-c to bring up the copy dialog

Expected behavior

darktable should allow me to interact with the dialogs every time

Logfile | Screenshot | Screencast

Here's a screencast I made where I tried to use preferences. It was unsuccessful a dozen times, before it was successful, so I trimmed it down to the last few attempts (including the successful one). You can tell when it isn't successful as nothing reacts when hovered and nothing is interactive).

https://github.com/darktable-org/darktable/assets/10246/43cd87fc-e844-422b-a748-2d0ee3d3637a

Here's a log file I created by running darktable --configdir darktable --library darktable.db . -d all > darktable-log.txt (which is separate from the video session, but it does have a few unsuccessful attempts when working with preferences and then a successful one): darktable-log.txt

Commit

No response

Where did you obtain darktable from?

distro packaging

darktable version

4.6.0

What OS are you using?

Linux

What is the version of your OS?

Fedora Linux 40.20240309.0 (Silverblue Prerelease)

Describe your system?

I'm using Fedora Silverblue 40 with GNOME 46 (release candidate) on Wayland. (This is the beta of what Fedora 40 will be next month.)

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

AMD Radeon RX 7900 XTX, 24 GB, RADV + ROCm

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

I've tried:

• darktable with OpenCL on
• darktable with OpenCL disabled
• new configuration in a directory of raw files darktable --configdir darktable --library darktable.db .
• the version of darktable from Flathub (4.6.1), which does not have GPU support

Everything I try seems to have this issue.

[garrett]

Since I'm running Silverblue, I'll try downgrading to Fedora 39 and try to see if this is a problem there or not.

[ptilopteri]

try with opencl disabled. there are well known problems with amd opencl drivers.

[gi-man]

I'm on Fedora 39 KDE without these issues. I run X11 on my main system. On a laptop I run fedora 39 KDE too, but on Wayland, just to test things. I dont see this problem in either system.

I did notice in your log a couple of xwayland input devices. Could they be causing an issue?

[garrett]

@ptilopteri: Yep, I already tried with OpenCL disabled (mentioned above), both with the Fedora package of darktable as well as the Flatpak from Flathub (which cannot even access OpenCL, sadly).

I've rebased to Fedora 39 and am having the same issue.

So, to summarize:

Dialogs are not interactive most of the time in both Fedora 39 and 40, whether OpenCL is on or off, and whether it's the Fedora package (4.6.0) for the Flathub package (4.6.1). One time out of many, the dialogs are interactive as they should be after opening and closing them several times (sometimes even as many times as 20 times to get them to work). I've tried it not just with my normal configuration, but also with a completely brand new settings too, with the same result.

This was not a problem with previous versions of darktable, prior to 4.6.0.

[garrett]

I did notice in your log a couple of xwayland input devices. Could they be causing an issue?

I'll try unplugging everything. I already did try unplugging my gamepad, but I didn't unplug the trackball. All of these same devices worked in the previous version of darktable, but it's definitely worth to try to figure out what's going on.

[garrett]

With nothing plugged in but my mouse and keyboard, I still see the same problem on Fedora 39.

I also tried removing my mouse and plugging the trackball back in. Additionally, turned off all GNOME Extensions (which should also not affect this, but eliminating anything it might be is still a good idea). It's still a problem.

[garrett]

Since Fedora 39 still has an X server, I tried that and don't see the issue.

However, I was running darktable prior to 4.6.0 in Wayland (via XWayland) without problems before. Did anything change regarding darktable with regard to Wayland or XWayland for the 4.6.0 release?

[garrett]

On Wayland:

• The problem as mentioned above: GDK_BACKEND=x11 darktable (this is the default anyway, but just confirming it by prefixing it with the variable)
• The problem with the interactive dialogs goes away with GDK_BACKEND=wayland darktable (However, this isn't a solution; there are several other issues, like size and placement problems with some widgets. According to the source, this is a known issue that isn't fixed yet.)

[garrett]

OK, I've figured it out! Thanks for your feedback, @gi-man!

1. GNOME on Wayland (this is the default for Fedora Workstation and Silverblue).
2. Have more than 1 monitor.
3. Have "Attach Modal Dialogs" turned on in GNOME (this is the default for GNOME, with no official way to change it).
4. Run darktable, and notice that most of the time, dialogs do not work. However, they do still work sometimes!

Note, Fedora is getting rid of X (other distributions are planning on doing so too), so there won't even be a fallback to use an X session soon.

I didn't see this problem before, as I usually just have 1 monitor on while working on photos and I usually have "Attach Modal Dialogs" turned off, but I guess I changed that back to default at some point in time. (Note: There's no way to even adjust this setting by default within GNOME. You have to know about it, install GNOME-Tweaks, find the setting, and turn it off. Alternatively, this command can also toggle the setting: gsettings set org.gnome.mutter attach-modal-dialogs false ­— regardless of if GNOME-Tweaks is installed or not.)

Anyway, the above steps are a way to reproduce this bug.

Edit: I've update the title and the original post to describe this bug more and list how to reproduce it.

[gi-man]

I know Wayland will be the default. I think I read I can still enable X server in F40. As more distros default to Wayland, it will force us to resolve issues. Maybe we should include your solution into the FAQ. I don't know if we could do something to avoid the problem within datktable.

I'm more concerned with color management and fractional scaling under Wayland, hence why I still use X server.

[garrett]

I'm more concerned with color management and fractional scaling under Wayland, hence why I still use X server.

Yeah, definitely. I miss my colorimeter, but use Wayland for other reasons (some other things work in Wayland but not in X (like gestures), or they work better in Wayland (multi-monitor support, render speed, security, etc.).

I think I read I can still enable X server in F40

At least, for now, in Fedora 40 beta's GNOME login screen, it seems to be there. Not sure about KDE... I know there was talk about removing X, but I think they went back on that and have it as an option for this upcoming release.

Perhaps I should consider switching back to X for a bit for color management until X is taken away completely in F41 (and by then, hopefully we finally have proper color management), especially since I'm trying to focus more on photography again.

Maybe we should include your solution into the FAQ. I don't know if we could do something to avoid the problem within datktable.

A not-that-great solution which is still probably better than not doing anything, might be to detect if:

• there's more than one monitor
• darktable is running on Xwayland
• GNOME + Wayland is being used
• if the attach-modal-dialogs is set to true

...And if all these conditions are met (remember that they're all the default except for > 1 monitor), then show a warning dialog that says something like "GNOME's default dialog handling interferes with darktable." and then have an option to "Change modal attachment setting" (which would run gsettings set org.gnome.mutter attach-modal-dialogs false behind the scenes) or "Ignore" (which would dismiss the dialog).

Something like this really should only be considered as a stopgap until there's a fix and/or improved Wayland support. It's still better than having mysteriously broken dialogs most of the time, however. People who are affected are most likely not going to go searching for a solution in a FAQ or other documentation. (It can still be documented, but people shouldn't have to read through a FAQ to be able to find a workaround to be able to use darktable.)

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[garrett]

It's not stale; it's part of what's needed for Wayland support.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[garrett]

With distributions dropping X support by default, Wayland support (to some degree, whether that is via XWayland or natively Wayland) becomes more important. This is still an issue for anyone on Wayland. While color management is still being worked on for Wayland and is important for many, not everyone using darktable has a colorimeter or color managed screens. At least the basic interaction of darktable should work from within Wayland in the interim.

TL;DR: Still a bug, not stale, and becomes more important with every new Linux distribution release (as more and more are moving away from X to Wayland).

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[garrett]

Not stale, still important as distros are dropping X for Wayland, and color management is (finally) on the way (and here in KDE) for Wayland too.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[garrett]

Still an issue

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[garrett]

(To the bot: Wayland is still growing in importance, as more and more distros are dropping X. Time hasn't changed that. If anything, time makes it even more important.)

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[lepolau]

Still an issue, on Arch with Darktable 5.0.1 from official repository. The only workaround is to work with a single screen / monitor.

[isamu1024]

Can confirm it is still an issue ( fedora 42 / Gnome )

[garrett]

BTW: GNOME 49, Fedora 43, and Ubuntu 25.10 are all dropping X11, replacing it with Wayland:

• https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98
• https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/99
• https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOME
• https://discourse.ubuntu.com/t/ubuntu-25-10-drops-support-for-gnome-on-xorg/62538

Of course, XWayland is still supported, but every big distro and desktop is moving to Wayland.

I know one of the issues with darktable on Wayland (aside from what was mentioned here) is color management. (This is actually one of the reasons I'm using X, even on Fedora 42 for the time being.) KDE added it earlier, but GNOME has added an extension for color management on Wayland (wp_color_management_v1) too:

• GNOME: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4291
• KDE: https://invent.kde.org/plasma/kwin/-/merge_requests/6255

[gi-man]

For the last ~6months, I've been using Fedora KDE on Wayland. Color management seems to work.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[garrett]

(Just a comment to un-stale-bot-ify.)

[gi-man]

@garrett are you still having the same issues in gnome?

[TheLostLambda]

@gi-man I'm definitely having these issues — it makes Darktable essentially unusable on my desktop PC!

If it's something that people think would be helpful, I can try to do a git-bisect to find the commit that introduced this bug?