darktable on Wayland: current status, major issues, and workarounds

Software darktable
,
1

Note: This post isn’t intended to report bugs, just to raise awareness of current issues, to set expectations, and provide some workarounds for the time being, until bugs are fixed.

I love darktable. It’s great. So many people here do too.

Those of us who use darktable in newer Linux distributions are about to face a major stability issue in darktable, if not already (as this also affects the current stable version of darktable, not just nightly builds from git).

While XWayland provides automatic compatibility for X apps in Wayland, darktable using XWayland (which it does by default) currently has a critical bug: It freezes after a few minutes when you have more than one display.

This issue is about to be even more problematic as multiple popular distributions (Fedora, Ubuntu, and downstreams of both) are moving to a Wayland-only default desktop. They’re even removing the option to install and use an Xorg display server entirely. Additionally, GNOME itself has already dropped Xorg support as a display server backend, so this is more widespread than “just” Fedora and Ubuntu.

Distros that will not have an X session available in GNOME (not even possible as a post-install):

GNOME itself (so every distro shipping GNOME will be affected, not just Fedora and Ubuntu and their downstreams):

As of the time of writing, this means darktable will not work properly at all for many people due to a few issues:

  1. In Wayland, darktable using XWayland (the X native compatability support in Wayland) means that darktable will freeze when you have more than one display.
  2. Launching darktable with the native Wayland backend now, thankfully, mostly works, even with more than one display. However, due to a bug, menus automatically close when trying to select a sub-menu. You’ll encounter this in darktable in a few places, such as selecting presets in modules (especially in heavily nested ones like in diffuse and sharpen module).
    • (Mentioned in bugs as an aside; does not seem to be reported yet.)
    • I assume this is probably an issue in darkable’s bauhaus widgets?
  3. Color management doesn’t currently work. It’s still relatively new in Wayland, and darktable and what’s in Wayland do not seem to work together yet, and colorimeters do not properly work in Wayland either (at least in GNOME; I don’t know if KDE has support for it yet, but I’ve seen people say it works in KDE).
  4. Drag and drop does not work in KDE on Wayland.

Hopefully someone can fix one or more of these above. (Color management is tricky and has been years in development and the thread here about it is super-long, so I wouldn’t expect that soon. But the others could possibly have a fix?)

For the time being, people will try darktable, find it is super unreliable and freezes within a few minutes of use, and not know that they can do a workaround (of turning off all screens but one). The workaround is annoying and undiscoverable (except through trial and error).

I’m not a darktable dev, but I’d guess the most crucial mitigation just to make darktable usable in Wayland (one way or another) would be to prioritize one of these two paths (although doing both would be great too):

  1. Fix the submenu issue and let darktable run in Wayland by default if it’s in Wayland. This doesn’t solve the other native Wayland issues, but they seem minimal compared to darktable not properly working at all.
  2. Debug the issue with freezing in darktable with multiple monitors (which doesn’t seem to show up in -d all). This would let the XWayland status quo otherwise work and not have to worry about Wayland native issues. But the debugging might be tricky.

The other Wayland issues of color management (at least in non-KDE environments) and drag and drop (at least in KDE) are not unimportant, but they don’t matter if darktable doesn’t work.

This all affects not just the upcoming version of darktable, but the current stable version of darktable too.

Meanwhile, if you’re going to have to use Wayland (and you have no choice not to when you’re using GNOME 49, in Fedora 43 and Ubuntu 25.10), you’ll need to run via XWayland and turn off any non-main screens. Or you’re going to run into problems.

For everyone here that uses darktable and would also be affected by this issue (using Wayland with more than one display, especially in GNOME), here’s a summary of what works and what doesn’t:

Environment Displays Backend Status
Wayland Multiple Monitors X11 (via XWayland) :x: Does not work: Application window randomly hangs/freezes.
Wayland Single or Multiple Monitors Wayland native (GDK_BACKEND=wayland) :warning: Almost works: Menus close when selecting sub-menus
Wayland Single Monitor X11 (via XWayland) :white_check_mark: Works
X session Any X11 :white_check_mark: Works

(This ignores color management and drag and drop and focuses on darktable working reliably or not.)

2 Likes
2

I have been using Wayland on Fedora Rawhide since one year with two monitors. No issues at all.

1 Like
3

Garret, I find your post a bit misleading. Fedora KDE Wayland on single monitor works without the issues listed above. The question is, what can dt do around the mutter/Wayland issues, if any? Is this a upstream issue that needs bug reports with mutter?

4

I’m not sure how this is misleading?

KDE on Wayland with a single monitor is not GNOME on Wayland with multiple monitors, which is where this freezing bug shows up, and which is why I wrote this (GNOME on Wayland on more than one monitor is definitely affected).

It might show up on more than GNOME, but it definitely shows up with more than one monitor on GNOME, and possibly elsewhere.

5

@01McAc Using GNOME? Or KDE or Sway or something else?

6

The title is this post is dt on Wayland. It leads to believe there is a major problem, but that’s not accurate. Like I said, I’ve been using Fedora KDE on Wayland for a while now. I have no issues with single monitor. I will try with dual when I get a chance.

Maybe the title should be dt on dual monitor in Gnome Wayland.

7

I’m using Manjaro, Gnome, wayland (as you can see in the screenshot) and using two displays.

image
image563×306 17.1 KB

Styles and presets menus and submenus work too:

image
image989×526 94.5 KB

image
image635×526 25.8 KB

It simply works as usual.

Am I missing something?

1 Like
8

I can confirm that I experienced DT freeze on Fedora 42 running Gnome on Wayland.

1 Like
9

@rgo: Oh, interesting!

  • What version of Manjaro?
  • Which version of GNOME?
  • Which darktable version?
  • How many monitors are you using?
  • And is this XWayland or the Wayland native mode of darktable?

Others in the issue are seeing the same problem I’m seeing too, at least on recent versions of GNOME. What versions are you using? Finding out where this problem shows up and where it isn’t is a good way to help debug what the problem is.

We’re seeing the submenu bug in Wayland native, not on XWayland. We’re seeing the issue with the freezing in XWayland on more than 1 monitor.

For everyone: Again, this issue is:

  1. Wayland-specific
  2. with more than one monitor
  3. using XWayland
  4. confirmed to be a problem at least on GNOME; we don’t know if it’s more than just GNOME or in GNOME only

The submenu bug is on Wayland mode when using GDK_BACKEND=wayland, which is not the default mode of darktable. We saw that issue when trying to find a workaround with the > 1 screen bug in Wayland when running darktable using XWayland (the default).

Since there hasn’t been a resolution yet, it made sense to try to narrow down the problem to help debug the issue and to raise awareness in case this isn’t solved by release.

Everyone using the upcoming versions of Fedora Workstation & Silverblue and also Ubuntu… and other distros that use GNOME 49 by default… will hit this problem by default if they have more than 1 monitor, so it’s kind of a big deal, as it causes darktable to not work at all after a few minutes. (No, it is not openCL related either. :wink: We all tested that.)

The freeze might be more widespread than GNOME, but it might not, so hearing from people who can test it can help. But there is also an issue with color management and also drag and drop at least in KDE.

10

Again, this actually is a major issue when running darktable on Wayland (via XWayland) on at least GNOME, but possibly elsewhere too. That’s why I posted here, to try to ask for help to figure out this issue, and to let people know that this is a problem.

The problem doesn’t show up when you have 1 monitor. It only shows up when you have more than 1 display, as I stated above.

It would be nice to know if this also affects KDE or not. Or Sway. Or any other Wayland desktop session. But you need more than one monitor, running in Wayland, and have darktable in XWayland (default, as you have to opt-into Wayland native right now).

And, also, I shared some additional Wayland-specific issues, such as XWayland in KDE (and apparently GNOME too — I just tested and posted the results to the issue) not accepting drag and drops. At least in GNOME, running darktable in Wayland native mode fixes that problem, and it accepts drag and drops (at least in GNOME). This is a regression in functionality but isn’t a critical issue though.

So, yes, this is also about darktable on KDE on Wayland, as I pointed out. But it might or might not be critical as running darktable in GNOME currently is (where it just stops to work at all within a couple minutes of launching it). But we don’t know, as someone with multiple monitors needs to test out darktable on Wayland. (And even still, you’re going to hit the drag and drop bug when using it with XWayland, which is still a Wayland-specific problem with darktable.)

Anyway, thanks everyone for looking into this and helping to debug it! Hopefully we can find out more details and share it on the issue.

1 Like
11

I just tested Fedora 42 KDE on wayland, GDK_BACKEND=wayland, two monitors (one needs calibration) and it all works fine. Submenus work too.

1 Like
12

Per your own words, it is only a confirmed issue when you run Gnome Wayland with more than one monitor. While it needs to be resolved, I cant agree with calling this a major issue. A major issue would be, folks cant run dt even with one monitor.

Per my post above, it works on KDE, so I think the GNOME users should look more into the GNOME compositor and report the bug upstream.

13

There is a Wayland native mode of darktable?

14

I have two monitors and I don’t get crashes using darktable 5.2.1 on KDE (Kubuntu 25.10) under Wayland using XWayland. Drag and drop to import images doesn’t work but I never do that anyway. Submenus work fine as far as I can tell.

15

If it helps, here’s a report on my experience on Arch Linux, GNOME 49:

User: randy
Model: HP ENVY TE01-1xxx
Distro: Arch Linux x86_64
Kernel: Linux 6.17.1-arch1-1
Window Manager: Not detected
Desktop Environment: GNOME
Shell: /usr/bin/bash
CPU: 16 x Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz
GPU: NVIDIA Corporation TU116 [GeForce GTX 1660 SUPER]
RAM: 5079 MiB / 31950 MiB
Disk: 733.0 GiB / 1.3 TiB

Running Darktable 5.2.1 on xwayland, with dual monitors, and I’ve never had any crashes or stability issues. I recently switched from the Nouveau driver to the proprietary Nvidia one, but I’ve never had trouble on either driver. I can confirm the menu bug running Darktable on Wayland, though.

HTH

1 Like
16

@garrett KDE only, currently v25.08.1
cat /etc/*release tells me:
Fedora release 44 (Rawhide)
NAME=“Fedora Linux”
VERSION=“44 (Workstation Edition Prerelease)”
RELEASE_TYPE=development
ID=fedora
VERSION_ID=44

But: KDE wayland is currently broken as PackageKit-Qt6 conflicts with another package. It is the first time since ages I need to use KDE-X11 since Thursday as long as it will be fixed.

17

Manjaro is a rolling release but latest stable ([Stable Update] 2025-09-26 - Kernels, NVIDIA, Systemd, LibreOffice, KDE Software - Stable Updates - Manjaro Linux Forum)

Gnome version 48

Dartkable version compiled from master (compiled yesterday but previous one was from 1 week).

I’m using 2 monitors (laptop and external)

In my system GDK_BACKEND is not set and there is no issue.
Setting it and loading it(GDK_BACKEND=wayland darktable) submenus in diffuse & sharpen stop working fine, I can’t select submenus. But no crash because of 2 displays.

18

(post deleted by author)

4 Likes
20

(post deleted by author)

1 Like