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

garrett commented 6 months ago

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

Use GNOME on Wayland (this is the default for Fedora Workstation and Silverblue).
Have more than 1 monitor.
Have "Attach Modal Dialogs" turned on in GNOME (this is the default for GNOME, with no official way to change it).
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 commented 6 months ago

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 commented 6 months ago

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

gi-man commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

GNOME on Wayland (this is the default for Fedora Workstation and Silverblue).
Have more than 1 monitor.
Have "Attach Modal Dialogs" turned on in GNOME (this is the default for GNOME, with no official way to change it).
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 commented 6 months ago

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 commented 6 months ago

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] commented 4 months ago

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 commented 3 months ago

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

github-actions[bot] commented 1 month ago

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 commented 1 month ago

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).

darktable-org / darktable