xorg-server 21.1.1-2 causes artifacts in darktable
This is for an up-to-date Arch Linux and AMD GPU (Radeon RX 5600 XT):
The xorg-server update to version 21.1.1-2 is causing an issue with darktable. darktable is then showing green squares as artifacts in the thumbnails.
https://github.com/darktable-org/darktable/issues/10386
Solution is to downgrade to the following packages from https://archive.archlinux.org/repos/2021/11/09/extra/os/x86_64/:
xf86-input-libinput-1.2.0-1-x86_64.pkg.tar.zst
xf86-input-vmmouse-13.1.0-5-x86_64.pkg.tar.zst
xf86-video-amdgpu-21.0.0-1-x86_64.pkg.tar.zst
xf86-video-ati-1 19.1.0-2-x86_64.pkg.tar.zst
xf86-video-fbdev-0.5.0-2-x86_64.pkg.tar.zst
xf86-video-intel-1 2.99.917+916+g31486f40-1-x86_64.pkg.tar.zst
xf86-video-vesa-2.5.0-1-x86_64.pkg.tar.zst
xf86-video-vmware-13.3.0-2-x86_64.pkg.tar.zst
xorg-server-1.20.13-3-x86_64.pkg.tar.zst
xorg-server-common-1.20.13-3-x86_64.pkg.tar.zst
xorg-xrdb-1.2.1-1-x86_64.pkg.tar.zstActivity
changed milestone to %xserver-21.1.x-next
I'm getting a similar issue in JetBrains IDEs since updating to xorg-server 21.1.1. Downgrading to 1.20.13 fixes the issue.
Confirming this issue happens with more than just darktable. It appears to happen with any X11 app, I just noticed it with GIMP and notice it in many apps when in an X11-based DE session.
Wayland-native apps are not affected.
Running Manjaro with an AMD Radeon 5600 XT.
Edited by Drew Walton@karzelek.piotr @drewwalton19216801 @pankmadafaki @saulfautley @mabod Which versions of the Linux kernel were you running?
This bug seems to be limited to AMD RDNA cards which I don't yet have one yet, it would be great to have more information about whether this is correct or not.
Yup I have an AMD RDNA graphics card (5600 XT). I run linux-zen on Arch. It must have been on 5.15 when I last tested.
Although this question was not directly addressed to me I want to give kernel information anyways. (whoops, I just see it was addressed to me as well ;-)
When I tested this the last time it was with Arch kernel 5.15.1 and 5.10.78 on EndeavourOS. My GPU still is
Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] vendor: Sapphire Limited driver: amdgpu v: kernel bus-ID: 0e:00.0 chip-ID: 1002:731fEdited by mabod@p12tic I just checked what happens if I update all of the mentioned above packages again... and it seems the bug is no longer there. I checked it after restart of course. Both, xorg and wayland sessions work properly with Intellij (Build #IU-213.5744.223, built on November 27, 2021) I use Manjaro with all updates installed today, Linux 5.16.5-1-MANJARO.
mentioned in issue #1359 (closed)
A quick test to disable GLAMOR in
Xwayland(as you said in #1359 (closed) that running Darktable inXwaylandcauses the same artifacts) is to set the envvarXWAYLAND_NO_GLAMOR=1prior to run your session (e.g. by adding it in/etc/environment).You'll need to restart your entire session for this change to be applied.
Note that this will negatively impact performance and can cause other problems (like running out of shared memory or file descriptors), the goal in this test is to determine if the regression can be caused by a change in glamor between 1.20 and 21.1.
Edited by Olivier Fourdan
I added
XWAYLAND_NO_GLAMOR=1to /etc/environmentAnd it solves the issue. I can start darktable in wayland without
GDK_BACKEND=waylandand I do NOT see the green square artefacts and the GUI is fine with the darktable leafs poping up right underneath the widget where they are supposed to be.This is with
xorg-xwayland 22.1.2-1but all the rest of xorg is downgraded to the versions I have mentioned at the beginning of this thread.Edited by mabodAs I wrote in #1359 (closed), the popup issue is a bug in Darktable, so let's ignore that for now.
If the icons look fine without GLAMOR, it means the regression here is introduced by a change in GLAMOR between 1.20 and 21.1.
Next would be for you to try to run a bisection in git to determine which exact change first introduced the problem.
It shouldn't be that hard actually.
Note, for this test to be meaningful, you need to remove
XWAYLAND_NO_GLAMOR=1from your/etc/environment, of course.You need to make sure you can build Xwayland from sources (i.e. you need to have the compiler, libraries, headers, etc. all installed on your system).
See here on how to build Xwayland: https://wayland.freedesktop.org/xserver.html#heading_toc_j_1
Once you can build Xwayland from sources, it's pretty straightforward, see here how to do a bisection in git: https://git-scm.com/docs/git-bisect
The idea is that you mark one past good revision as "good", and current revision as "bad", then build and test each step and mark each step as good or bad, until you end up on the first "bad" commit that introduced the issue.
You do not have to install Xwayland each time, you can run it rootfull directly from the meson build tree, e.g.:
./build/hw/xwayland Xwayland :12That will map a fullscreen black window (this is actually Xwayland's root window), and then you can test with Darktable using the
DISPLAY=:12, i.e.:DISPLAY=:12 darktableIf the icons look "fine", then you mark the commint as good with
git bisect good, whereas if the icons look "bad", then you mark it bad withgit bisect bad.Each time you mark the currect commit as good or bad, git will select (by dichotomy) another commit to try until there is only one left.
Easy :)
I did my first test. But compilation failed with the following error:
Run-time dependency fontutil found: NO (tried pkgconfig and cmake) meson.build:143:4: ERROR: Dependency "fontutil" not found, tried pkgconfig and cmakeI can not find a package whcih is called fontutil. Where do I find that?
And secondlay, the command is
meson -Dprefix=$WLD ...what is $WLD? I have set it to /usr/local/xayland. Is that ok?
Meanwhile I got this sorted out. xorg-font-util is the package that was missing.
The compilation is going through. it installs in /usr/local/xwayland/. But when I want to start it with:
/usr/local/xwayland//bin/Xwayland :12I get the following error:
# Xwayland :12 (EE) Fatal server error: (EE) error: XDG_RUNTIME_DIR is invalid or not set in the environment. (EE)Somehow I do not get the result I expected. First I try to find a point in time were it was working. So I am doing a
git reset c6ab2102
Which puts the source back to xorg-server-1.19.99.905. Compilation works fine. git status says "Your branch is behind 'origin/master' by 1274 commits,"
Then I start
/usr/local/xwayland//bin/Xwayland :12and
DISPLAY=:12 GDK_BACKEND=x11 darktableBut that still gives me the artefacts.
Oh wait… you said
git reset c6ab21022?A simple
git resetdoesn't change the code!
Try a
git statusand see by yourself.Better use
git checkout c6ab21022insteadEdited by Olivier FourdanTry this instead:
- Go back to the original starting point
$ git reset --hard origin/master- Mark that one as "bad" (we know it's bad anyway)
$ git bisect bad You need to start by "git bisect start" Do you want me to do it for you [Y/n]?- Go back to
7437b6dbd(the first commit toglamor/after the 1.20 branch)
$ git checkout 7437b6dbd Note: switching to '7437b6dbd'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 7437b6dbd glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays- Try to configure/build:
$ meson --buildtype=plain -Dxkb_dir=/var/lib/xkb -Dxkb_bin_dir=/usr/bin/ . buildThat will fail actually, with:
Configuring xwayland-config.h using configuration Run-time dependency glproto found: YES 1.4.17 Dependency gl found: NO found 1.2 but need: '>= 9.2.0' Run-time dependency gl found: NO (tried system) glx/meson.build:35:4: ERROR: Invalid version of dependency, need 'gl' ['>= 9.2.0'] found '1.2'. A full log can be found at xserver/build/meson-logs/meson-log.txtThis is because there are a few commits that are needed to be able to build with recent libraries, namely:
- 741bd734 glamor/xwayland: Define EGL_NO_X11
- 3340ddf3 meson: Apparently 1.2 is < 1.2.0
- c7486613 meson: Fix another reference to "gl" 9.2.0
- e6ef2b12 build: glx: Lower gl version to work with libglvnd
-
435d41d5 Fix building with
-fno-common
So for example, to be able to build the first iteration, you'll need to apply that first:
$ git show e6ef2b124 c7486613b 3340ddf37 435d41d5f | git applyThen redo the "meson configuration" step, it will succeed and you can try to build:
$ meson --buildtype=plain -Dxkb_dir=/var/lib/xkb -Dxkb_bin_dir=/usr/bin/ . build $ meson compile -C build/ ... [670/670] Linking target hw/xwayland/Xwayland- Try the build:
./build/hw/xwayland/XWayland :12- Revert any of the patches we had to apply to be able to build
$ git checkout -- .- And mark the commit as either "good" or "bad" depending on the result:
$ git bisect good or $ git bisect bad- Repeat until the bisection is complete.
Depending on where you are in the git history, you may need to apply all, some or none of the patches I listed above to be able to build.
Edited by Olivier FourdanThat is a very good tutorial!
I could do step 1-4, but step 5 - the excution of Xwayland - fails:
# ./build/hw/xwayland/Xwayland :12 (EE) (EE) Backtrace: (EE) 0: ./build/hw/xwayland/Xwayland (0x56364f653000+0x1f6cae) [0x56364f849cae] (EE) 1: ./build/hw/xwayland/Xwayland (0x56364f653000+0x1fafb5) [0x56364f84dfb5] (EE) 2: /usr/lib/libc.so.6 (0x7f633ce00000+0x3e8e0) [0x7f633ce3e8e0] (EE) 3: /usr/lib/libwayland-client.so.0 (wl_proxy_get_version+0x4) [0x7f633d5289d4] (EE) 4: ./build/hw/xwayland/Xwayland (0x56364f653000+0x26c47) [0x56364f679c47] (EE) 5: ./build/hw/xwayland/Xwayland (0x56364f653000+0x28178) [0x56364f67b178] (EE) 6: ./build/hw/xwayland/Xwayland (0x56364f653000+0x10f71d) [0x56364f76271d] (EE) 7: ./build/hw/xwayland/Xwayland (0x56364f653000+0x105d89) [0x56364f758d89] (EE) 8: ./build/hw/xwayland/Xwayland (0x56364f653000+0x10035b) [0x56364f75335b] (EE) 9: ./build/hw/xwayland/Xwayland (0x56364f653000+0xc6064) [0x56364f719064] (EE) 10: ./build/hw/xwayland/Xwayland (0x56364f653000+0x3b171) [0x56364f68e171] (EE) 11: /usr/lib/libc.so.6 (0x7f633ce00000+0x29290) [0x7f633ce29290] (EE) 12: /usr/lib/libc.so.6 (__libc_start_main+0x8a) [0x7f633ce2934a] (EE) 13: ./build/hw/xwayland/Xwayland (0x56364f653000+0x26995) [0x56364f679995] (EE) (EE) Segmentation fault at address 0x40 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) zsh: IOT instruction (core dumped) ./build/hw/xwayland/Xwayland :12Yikes! That's because older Xwayland rootfull required the Wayland protocol
wl_shellwhich is now removed from GNOME Shell/mutter (deprecated in favor ofxdg-shell).This was fixed in Xwayland with commit 3d6efc4a but that commit won't apply on older versions of Xwayland, so we cannto do the
git show | git applydance there.A possible solution would be to downgrade GNOME Shell to GNOME 41, but that might pull a lot of dependencies…
I did a first test with Xephyr.
I installed
xorg-server-xephyr 21.1.3-7from the Arch repo. I started xephyr with:Xephyr -br -ac -noreset -screen 2400x1080 -glamor :12I started darktable with:
DISPLAY=:12 darktableAnd I see the artefacts.
How do I proceed now with the git bisect for xephyr?
And I see the artefacts.
How do I proceed now with the git bisect for xephyr?Right, it's a good start, we also need to make sure the "old" Xephyr did not show the artefacts, but that's part of the bisection.
- As you were in the middle of an (aborted) bisection, you'll need to do a
git bisect resetto make sure we start from a clean sheet:
$ git bisect reset Previous HEAD position was 7437b6dbd glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays Switched to branch 'master' Your branch is up to date with 'origin/master'.- Redo the meson config again, enabling
xephyrandglamorthis time, and disabling the rest:
$ meson --reconfigure --buildtype=plain -D{xephyr,glamor}=true -D{xwayland,xorg,xnest}=false . build […] User defined options buildtype: plain glamor : true xephyr : true xnest : false xorg : false xwayland : false- And build:
$ meson compile -C build/ ninja: Entering directory `/home/ofourdan/src/wayland/xserver/build' [436/436] Linking target hw/kdrive/ephyr/Xephyr- Make sure
Xephyris there and has the artefacts
$ ./build/hw/kdrive/ephyr/Xephyr -br -ac -noreset -screen 2400x1080 -glamor :12 & $ DISPLAY=:12 darktable (Then stop both `Xephyr` and `darktable`)- Mark this commit "bad" (that's of course assuming the artefacts are there!)
$ git bisect bad You need to start by "git bisect start" Do you want me to do it for you [Y/n]? Y- Go back to 7437b6db (the first commit to glamor/ after the 1.20 branch)
$ git checkout 7437b6dbd Note: switching to '7437b6dbd'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 7437b6dbd glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays- Rebuild with the "old" code
$ meson compile -C build/ […] Dependency glproto found: YES 1.4.17 (cached) Dependency gl found: NO found 1.2 but need: '>= 9.2.0' Run-time dependency gl found: NO (tried system) ../glx/meson.build:35:4: ERROR: Invalid version of dependency, need 'gl' ['>= 9.2.0'] found '1.2'. A full log can be found at xserver/build/meson-logs/meson-log.txt FAILED: build.ninja /usr/bin/meson --internal regenerate xserver xserver/build --backend ninja ninja: error: rebuilding 'build.ninja': subcommand failedNormal, same as before, the "old" code needs a few tweaks to build with the more recent stack.
- 741bd734 glamor/xwayland: Define EGL_NO_X11
- 3340ddf3 meson: Apparently 1.2 is < 1.2.0
- c7486613 meson: Fix another reference to "gl" 9.2.0
- e6ef2b12 build: glx: Lower gl version to work with libglvnd
-
435d41d5 Fix building with
-fno-common
So for example, to be able to build this first iteration, you'll need to apply that first:
$ git show e6ef2b124 c7486613b 3340ddf37 435d41d5f | git applyAnd retry the build:
$ meson compile -C build/If you get an error such as:
../meson.build:104:4: ERROR: 'xkbcomp' is not a pkgconfig dependencyYou need to install the development package for
xkbcomp(that varies with the distributions, so I cannot tell how to do that on your distribution).If all goes well, it should build:
$ meson compile -C build/ […] [425/425] Linking target hw/kdrive/ephyr/Xephyr- Try this "new" build from the "old" code and make sure it does not show the artefacts:
$ ./build/hw/kdrive/ephyr/Xephyr -br -ac -noreset -screen 2400x1080 -glamor :12 & $ DISPLAY=:12 darktableAt this point, if the artefacts are still there, then the bisection is probably useless.
- Clean your local repository (remember we applied some changes to be able to build):
$ git checkout -- .- And mark this commit as "good" (Again, this is assuming the artefacts are not there):
$ git bisect good Bisecting: 617 revisions left to test after this (roughly 9 steps) [8315fc4ea2e04598ce0c7e9771786a9334f0d456] modesetting: add support for GBM_FORMAT_RGB565So you know that you'll need to repeat this approximately 9 more times :)
- Rebuild
Xephyrat this new commit
$ meson compile -C build/ […] [429/429] Linking target hw/kdrive/ephyr/XephyrThis time, it should build, no need to apply any patch because we're at a point more recent in time.
- Re-test again
$ ./build/hw/kdrive/ephyr/Xephyr -br -ac -noreset -screen 2400x1080 -glamor :12 & $ DISPLAY=:12 darktableAnd mark the commit as "good" or "bad" depending on the result.
Each step you make, you may have to apply some of the commits I listed to be able to build (that obviously depends on the actual bisection, so I cannot tell that in advance… it would be too easy!)
Have fun! :)
Edited by Olivier Fourdan- As you were in the middle of an (aborted) bisection, you'll need to do a
I have a first result. I did the bisect two times. And it gave me the same result both times, which is a good sign I think ;-)
# git bisect good 8702c938b33b9ec180d64754eb922515c7c4a98b is the first bad commit commit 8702c938b33b9ec180d64754eb922515c7c4a98b Author: Eric Anholt <eric@anholt.net> Date: Tue Mar 26 15:10:49 2019 -0700 glamor: Introduce a central place for our pixmap format/type handling. We had various helper functions trying to come up with the internalformat/format/type/render formats for pixmaps, and it's much nicer to just detect what those should be once at startup. This gives us a chance to do the right thing for GLES. It also, notably, fixes our format/type for depth 15 and 16 setup for desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most drivers instead of 32bpp (GL_RGB/UBYTE). GLES still has regressions over desktop (2 regressions in llvmpipe XTS, many in rendercheck), but I think this is a good baseline. Signed-off-by: Eric Anholt <eric@anholt.net> glamor/glamor.c | 167 ++++++++++++++++++++++++++++++++++++++++++++-- glamor/glamor_fbo.c | 16 ++--- glamor/glamor_picture.c | 7 +- glamor/glamor_priv.h | 22 +++++- glamor/glamor_render.c | 7 +- glamor/glamor_spans.c | 14 ++-- glamor/glamor_transfer.c | 56 ++-------------- glamor/glamor_transfer.h | 3 - glamor/glamor_transform.c | 5 +- glamor/glamor_utils.h | 57 ---------------- 10 files changed, 209 insertions(+), 145 deletions(-)Thanks! That's extremely helpful!
That's a fairly large commit that caused some regression in the past (as with commit e59e24c8) but in this particular case, I wonder if the bug is in the change itself or the change triggers a bug elsewhere in the stack (rationale being, it seems to be limited to some specific hardware).
Edited by Olivier Fourdan@anholt any ideas?
@mabod can you please give this branch a try and see if that solves the issue for you:
$ git fetch git@gitlab.freedesktop.org:ofourdan/xserver.git test-for-issue-1250 $ git checkout -b test-for-issue-1250 FETCH_HEAD $ meson compile -C build/ $ ./build/hw/kdrive/ephyr/Xephyr -br -ac -noreset -screen 2400x1080 -glamor :12 & $ DISPLAY=:12 darktableMaybe it's a shot in the dark, but it seems this is a format which changed with commit 8702c938.
Edited by Olivier FourdanI have no access:
# git fetch git@gitlab.freedesktop.org:ofourdan/xserver.git test-for-issue-1250 git@gitlab.freedesktop.org: Permission denied (publickey,keyboard-interactive). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.@mabod Try
git fetch https://gitlab.freedesktop.org/ofourdan/xserver.git test-for-issue-1250Ah too bad… Up for another quick test?
I've changed the commit but kept the branch, so you'll need to re-fetch the branch once again and do a
git checkout -B, with a capital „B“ this time, i.e.:$ git fetch https://gitlab.freedesktop.org/ofourdan/xserver.git test-for-issue-1250 $ git checkout -B test-for-issue-1250 FETCH_HEAD $ meson compile -C build/ $ ./build/hw/kdrive/ephyr/Xephyr -br -ac -noreset -screen 2400x1080 -glamor :12 & $ DISPLAY=:12 darktableDoes that make any difference?
Edited by Olivier FourdanIt gives:
ceb63ecf0 (HEAD -> test-for-issue-1250) glamor: Use GL_UNSIGNED_BYTE for data typeAnd I started from scratch with a fresh clone of xserver.
Edited by mabodFor me the most irritating thing is, that the artifacts only show on thumbnails in darktable. The RAW pictures itself and all the rest of darktable is just fine. And so is the rest of the desktop. gimp also has some small artifacts with some widgets. But also here the pictures itself is fine.
And in darktable the artifacts go away when I hover the mouse over the thumbnail. As soon as I move the mouse away, the artifacts are back.
I dont know if it helps, but here is just one example of a darktable thumbnail file.
I can confirm exactly the same behavior in IntelliJ and Gimp. Haven't tried Darktable.
Interesting thing is that in my case it works fine when I use Xephyr (built on any commit mentioned here) under Wayland. It just doesn't work with the implicit xwayland apps
Edited by Jakub Petržílka
