Whenever I run `dmesg' on a xterm that uses the following options: xterm -fa "DejaVu Sans Mono:style=Book:antialias=true" -fs 9 and I scroll up with the keyboard (shift+page up) parts of the scrollback buffer disappears, making it difficult to read the output. I've tested other terminals (urxvt and alacritty) and I cannot trigger the bug with these terminals, with xterm it happens only with xft and with the options I mentioned above. Steps to reproduce: - run `xterm -fa "DejaVu Sans Mono:style=Book:antialias=true" -fs 9' - run `dmesg', hit enter and page up You should notice parts of the buffer disappearing. I use the modesetting DDX driver, I also tried the xf86-video-amdgpu DDX driver and I can reproduce it with both, however, when setting Option "Accel" "off" in /etc/X11/xorg.conf.d/20-amdgpu.conf I cannot reproduce it anymore. Actual Results: As mentioned, the scrollback buffer disappears when paging up with these xterm options that I mentioned above. Expected Results: xterm works normally with these options, with no scrollback buffer issues. System details: - Arch Linux (x86_64) - linux 5.0.2-arch1-1-ARCH - xorg-server 1.20.4-1 - i3-wm 4.16.1-1 - xterm 344-1 - mesa 19.0.0-1 My machine is a "AMD Ryzen 5 2400G with Radeon Vega Graphics" APU with integrated vega graphics. $ lspci | grep VGA 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c6)
Please attach the corresponding Xorg log file and output of glxinfo and dmesg. I can't seem to reproduce this, and I'm not sure what exactly "parts of the scrollback buffer disappear" means. Maybe you can make a screencast or screenshots demonstrating the problem? Anyway, this is more likely an issue between glamor and Mesa than in the kernel driver. Reassigning to Mesa for now, as glamor issues are no longer tracked here.
Created attachment 143749 [details] Screencast demonstrating the problem
Created attachment 143750 [details] Xorg.0.log
Created attachment 143751 [details] glxinfo
Created attachment 143752 [details] dmesg
(In reply to Michel Dänzer from comment #1) > Please attach the corresponding Xorg log file and output of glxinfo and > dmesg. Done. > > I can't seem to reproduce this, and I'm not sure what exactly "parts of the > scrollback buffer disappear" means. Maybe you can make a screencast or > screenshots demonstrating the problem? By that I mean the actual text/output disappears after I do shift+page up, but it doesn't if I scroll with the mouse wheel or if I use the scrollbar. I've attached a video demonstrating the issue, please let me know if you need more info. Thanks.
(In reply to Diego Viola from comment #6) > (In reply to Michel Dänzer from comment #1) > > Please attach the corresponding Xorg log file and output of glxinfo and > > dmesg. > > Done. > > > > > I can't seem to reproduce this, and I'm not sure what exactly "parts of the > > scrollback buffer disappear" means. Maybe you can make a screencast or > > screenshots demonstrating the problem? > > By that I mean the actual text/output disappears after I do shift+page up, > but it doesn't if I scroll with the mouse wheel or if I use the scrollbar. That was wrong, using the scrollbar also causes the same effect as using shift+page up (disappearing text).
I've compiled mesa from git and the issue is still there, I also tried older releases like 18.3, 18.2 and the issue remains.
I also get the same issue if I run xterm from sway/weston (via xwayland).
My issue looks quite similar to this one: https://bugs.openbsd.narkive.com/N7A1v1Cw/colored-text-disappears-in-xterm
Tried mesa git (19.1.0-devel) with LLVM 9.0.0 (SVN) and the issue still persists.
I also tried recompiling xorg-server (git and 1.20.0) and the problem still persists with those, I can't compile older releases anymore due to compile time errors.
I can also reproduce the issue with Xephyr -glamor.
I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWARE=1.
(In reply to Diego Viola from comment #14) > I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWARE=1. How exactly did you set that? Normally, I'd expect it to only affect clients, not the X server. Are you using a compositing manager?
(In reply to Michel Dänzer from comment #15) > (In reply to Diego Viola from comment #14) > > I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWARE=1. > > How exactly did you set that? Normally, I'd expect it to only affect > clients, not the X server. > > Are you using a compositing manager? In my TT1: export LIBGL_ALWAYS_SOFTWARE=1 then startx after that. When I'm on X, I open an xterm and LIBGL_ALWAYS_SOFTWARE=1 will be set, glxinfo also reports llvmpipe. I'm using i3-wm, no I don't use a compositing manager.
TTY1, sorry.
I tried running xcompmgr just to see if it makes a difference and it doesn't, I can still reproduce the bug when xcompmgr is running.
(In reply to Diego Viola from comment #12) > I also tried recompiling xorg-server (git and 1.20.0) and the problem still > persists with those, [...] Did you build xserver with meson or autotools?
(In reply to Michel Dänzer from comment #19) > (In reply to Diego Viola from comment #12) > > I also tried recompiling xorg-server (git and 1.20.0) and the problem still > > persists with those, [...] > > Did you build xserver with meson or autotools? autotools
BTW, I'm not sure if it's related, but I also started seeing some artifacts with GTK windows (GIMP and LibreOffice), items such as "Help" (in GtkMenuItem) will disappear, then they re-appear until I click in one of them. The same is also true for the text in the menus itself.
s/until/when/
When starting X with LIBGL_ALWAYS_SOFTWARE=1 the rendering issues with GIMP also goes away.
I've bisected the issue with the GTK elements sometimes disappearing, and the commit that causes the issue is this one: 1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit Sadly my xterm is still affected but I can confirm this commit causes the issue with the GTK windows, going back to the previous commit fixes the issue with the invisible element in GIMP. Does it shed any light for my original issue (invisible output in xterm)? Sorry for mixing things up.
Just to make sure, you always restart the X server between building a Mesa commit and testing xterm against it, right? And you're making sure that the X server picks up your self-built radeonsi_dri.so for glamor? If so, since that commit doesn't seem to affect the xterm issue, let's assume for now that it's separate. Please file a new report about the GTK issue, also against radeonsi, with the information from git bisect.
(In reply to Michel Dänzer from comment #25) > Just to make sure, you always restart the X server between building a Mesa > commit and testing xterm against it, right? And you're making sure that the > X server picks up your self-built radeonsi_dri.so for glamor? Yes. > > If so, since that commit doesn't seem to affect the xterm issue, let's > assume for now that it's separate. Please file a new report about the GTK > issue, also against radeonsi, with the information from git bisect. OK.
Actually, about your question: > And you're making sure that the X server picks up your self-built radeonsi_dri.so for glamor? I'm compiling Mesa in my home directory with the following configure switches: ./autogen.sh --enable-gles1 --enable-gles2 --enable-glx-tls --with-egl-platforms=x11,drm,wayland --with-dri-drivers=radeon --with-gallium-drivers=radeonsi --enable-debug --enable-autotools make -j8 export LD_LIBRARY_PATH=/home/diego/mesa/lib export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium So I assume this should make the X server pick the radeonsi_dri.so from /home/diego/mesa/lib/gallium right? I looked at the ~/.local/share/xorg/Xorg.0.log but it's not so clear: [ 437.304] (II) modeset(0): [DRI2] DRI driver: radeonsi [ 437.307] (II) AIGLX: Loaded and initialized radeonsi Is there a way to verify beyond this which radeonsi driver it's using?
I guess I'll need to install mesa system wide to be really sure, I'll do that and confirm.
OK, I was able to install Mesa system wide, glxinfo tells me this: Mesa 19.0.0-devel (git-8daf5bb209) Which is the commit prior to the bad commit I mentioned above. Sadly xterm is still breaking as usual, the output disappears as I Shift+Page Up and nothing changed in that regard. :(
I can reproduce this on Fedora 29 (workstation), I don't think the problem is Arch Linux specific. - XTerm(334) - Linux 5.0.4-200.fc29.x86_64 - GNOME Version 3.30.2 - xorg-x11-server-Xorg-1.20.4-1.fc29.x86_64
I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta.
(In reply to Diego Viola from comment #27) > export LD_LIBRARY_PATH=/home/diego/mesa/lib > export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium > > So I assume this should make the X server pick the radeonsi_dri.so from > /home/diego/mesa/lib/gallium right? Doubtful, environment variables from the user shell aren't propagated to the Xorg process for me (which makes it very mysterious how LIBGL_ALWAYS_SOFTWARE=1 could make any difference...). > Is there a way to verify beyond this which radeonsi driver it's using? sudo lsof | grep radeonsi_dri.so (In reply to Diego Viola from comment #29) > Mesa 19.0.0-devel (git-8daf5bb209) > > Which is the commit prior to the bad commit I mentioned above. > > Sadly xterm is still breaking as usual, the output disappears as I > Shift+Page Up and nothing changed in that regard. :( What if you install Mesa 18.3 system-wide? (In reply to Diego Viola from comment #30) > I can reproduce this on Fedora 29 (workstation), [...] (In reply to Diego Viola from comment #31) > I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta. Please attach the outputs of glxinfo from Fedora and Ubuntu.
Created attachment 143829 [details] glxinfo from Ubuntu 19.04 beta
Created attachment 143830 [details] glxinfo from Ubuntu 18.04.2
Created attachment 143831 [details] glxinfo from Fedora 29
(In reply to Michel Dänzer from comment #32) > (In reply to Diego Viola from comment #27) > > export LD_LIBRARY_PATH=/home/diego/mesa/lib > > export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium > > > > So I assume this should make the X server pick the radeonsi_dri.so from > > /home/diego/mesa/lib/gallium right? > > Doubtful, environment variables from the user shell aren't propagated to the > Xorg process for me (which makes it very mysterious how > LIBGL_ALWAYS_SOFTWARE=1 could make any difference...). > > > Is there a way to verify beyond this which radeonsi driver it's using? > > sudo lsof | grep radeonsi_dri.so Thanks. > > > (In reply to Diego Viola from comment #29) > > Mesa 19.0.0-devel (git-8daf5bb209) > > > > Which is the commit prior to the bad commit I mentioned above. > > > > Sadly xterm is still breaking as usual, the output disappears as I > > Shift+Page Up and nothing changed in that regard. :( > > What if you install Mesa 18.3 system-wide? I'll try that. > > > (In reply to Diego Viola from comment #30) > > I can reproduce this on Fedora 29 (workstation), [...] > (In reply to Diego Viola from comment #31) > > I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta. > > Please attach the outputs of glxinfo from Fedora and Ubuntu. Done.
Hmm, Mesa was built against LLVM 7 in Arch & Fedora, against LLVM 8/9 in Ubuntu. Maybe this was an LLVM issue fixed in version 8?
(In reply to Michel Dänzer from comment #37) > Hmm, Mesa was built against LLVM 7 in Arch & Fedora, against LLVM 8/9 in > Ubuntu. Maybe this was an LLVM issue fixed in version 8? Unfortunately that's not the issue, llvm-libs 8.0.0 just landed on Arch Linux [extra] repository and the issue still persists.
(In reply to Diego Viola from comment #38) > Unfortunately that's not the issue, llvm-libs 8.0.0 just landed on Arch > Linux [extra] repository and the issue still persists. Has Mesa been rebuilt against the new LLVM? Check the glxinfo output.
Something really funny is going on. I've compiled Mesa 18.3.0 and installed it system-wide and that works (xterm scrollback is fine with this). I've compiled the latest Mesa git HEAD and installed that system-wide, this fails. Bisect time.
$ git bisect good 6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit commit 6328536ff28ca26f2ad4e6f2c956c467acebda88 Author: Eric Anholt <eric@anholt.net> Date: Fri Nov 2 14:35:06 2018 -0700 gbm: Introduce a helper function for printing GBM format names. This requires that the caller make a little (stack) allocation to store the string. v2: Use gbm_format_canonicalize (suggested by Daniel) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> :040000 040000 033db8e2d54ead2f34691e6b8e234a06428381fd 50d5e1cbd57b488d0e24fd86787c611bf58bd588 M src
Created attachment 143832 [details] git bisect log
(In reply to Diego Viola from comment #41) > $ git bisect good > 6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit > commit 6328536ff28ca26f2ad4e6f2c956c467acebda88 > Author: Eric Anholt <eric@anholt.net> > Date: Fri Nov 2 14:35:06 2018 -0700 > > gbm: Introduce a helper function for printing GBM format names. > > This requires that the caller make a little (stack) allocation to store > the string. > > v2: Use gbm_format_canonicalize (suggested by Daniel) > > Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> > Reviewed-by: Daniel Stone <daniels@collabora.com> > > :040000 040000 033db8e2d54ead2f34691e6b8e234a06428381fd > 50d5e1cbd57b488d0e24fd86787c611bf58bd588 M src I'm afraid this is a red herring: as you can see from looking at the commit, it simply adds new API with no actual user.
(In reply to Daniel Stone from comment #43) > (In reply to Diego Viola from comment #41) > > $ git bisect good > > 6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit > > commit 6328536ff28ca26f2ad4e6f2c956c467acebda88 > > Author: Eric Anholt <eric@anholt.net> > > Date: Fri Nov 2 14:35:06 2018 -0700 > > > > gbm: Introduce a helper function for printing GBM format names. > > > > This requires that the caller make a little (stack) allocation to store > > the string. > > > > v2: Use gbm_format_canonicalize (suggested by Daniel) > > > > Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> > > Reviewed-by: Daniel Stone <daniels@collabora.com> > > > > :040000 040000 033db8e2d54ead2f34691e6b8e234a06428381fd > > 50d5e1cbd57b488d0e24fd86787c611bf58bd588 M src > > I'm afraid this is a red herring: as you can see from looking at the commit, > it simply adds new API with no actual user. Are you sure? I've compiled the previous commit and that makes it work. commit ee7f848c000112a98e9614f42921b176be473792 (HEAD) Should I restart the git bisect?
Created attachment 143833 [details] glxinfo with LLVM 8.0.0 (In reply to Michel Dänzer from comment #39) > (In reply to Diego Viola from comment #38) > > Unfortunately that's not the issue, llvm-libs 8.0.0 just landed on Arch > > Linux [extra] repository and the issue still persists. > > Has Mesa been rebuilt against the new LLVM? Check the glxinfo output. Here's the current glxinfo output with the stock mesa on Arch.
For some reason glxinfo reports mesa 19.0.0 (stock package on Arch) after I've installed mesa system-wide (18.3.0). I didn't use a PKGBUILD and installed mesa by doing a `sudo make install'. Maybe that's why the bisect went bad? I know using a PKGBUILD is the right way to do it, but the last time I tried to use it I got some conflicts with libglvnd when I tried to replace the Arch Linux mesa package with the custom one.
OK, this one is also weird, I've compiled mesa-18.3.0 in my home directory, exported these two variables: export LD_LIBRARY_PATH=/home/diego/mesa/lib export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium I startx after that, glxinfo reports the right mesa version (18.3.0) and lsof says this: $ sudo lsof | grep radeonsi_dri.so [sudo] password for diego: Xorg 8082 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8083 Xorg:cs0 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8084 Xorg:disk diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8085 Xorg:sh0 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8086 Xorg:sh1 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8087 Xorg:sh2 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8088 Xorg:sh3 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8089 Xorg:sh4 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8090 Xorg:sh5 diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8091 Xorg:shlo diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8092 Xorg:shlo diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8093 Xorg:shlo diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8094 Xorg:shlo diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so Xorg 8082 8095 Xorg:gdrv diego mem REG 0,22 84191168 322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so But then I cannot reproduce the bug anymore. Any ideas?
Created attachment 143834 [details] Xephyr.trace Here is an apitrace to reproduce the bug, I used this: export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" apitrace trace /usr/bin/Xephyr -glamor :1 -screen 1024x768 As described here: https://github.com/apitrace/apitrace/wiki/Glamor I can replay it with either of those commands: eglretrace -w Xephyr.trace or glretrace -w Xephyr.trace This was iive's suggestion (thanks).
apitrace replay -w Xephyr.trace also seems to work.
I can reproduce the issue with apitrace on Ubuntu 19.04.
(In reply to Diego Viola from comment #46) > Maybe that's why the bisect went bad? That's likely one reason at least. At this point it's probably best if you double-check everything before testing anything. :) (In reply to Diego Viola from comment #47) > But then I cannot reproduce the bug anymore. The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, so that makes sense?
(In reply to Michel Dänzer from comment #51) > (In reply to Diego Viola from comment #46) > > Maybe that's why the bisect went bad? > > That's likely one reason at least. At this point it's probably best if you > double-check everything before testing anything. :) Sure, sorry about any possible false-positives that I might have provided by accident. > > (In reply to Diego Viola from comment #47) > > But then I cannot reproduce the bug anymore. > > The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, > so that makes sense? Yes, is there any more info that I can provide that you think would be useful? Thanks.
It's probably worth trying git bisect again, double-checking at each step that you're testing the right thing.
(In reply to Michel Dänzer from comment #53) > It's probably worth trying git bisect again, double-checking at each step > that you're testing the right thing. Sure, I think my attempt from #c47 should have allowed me to reproduce the problem, I wonder why that failed. I will try again.
(In reply to Michel Dänzer from comment #53) > It's probably worth trying git bisect again, double-checking at each step > that you're testing the right thing. I tried again and I can't get to replace the system mesa with my own build because of some conflicts with libglvnd, and when I compile mesa in my home directory and export LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH to my mesa build, glxinfo reports the right version of mesa and links to the libGL from my build, but lsof shows the libGL from libglvnd is being used.
Here's more or less what I'm currently seeing: $ ldd /usr/bin/glxinfo | grep libGL libGL.so.1 => /home/diego/mesa/lib/libGL.so.1 (0x00007fbaac886000) $ ls -l /home/diego/mesa/lib/libGL.so.1 lrwxrwxrwx 2 diego diego 14 Apr 2 00:03 /home/diego/mesa/lib/libGL.so.1 -> libGL.so.1.2.0 $ sudo lsof | grep libGL.so [sudo] password for diego: Xorg 4873 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4874 Xorg:cs0 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4875 Xorg:disk diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4876 Xorg:sh0 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4877 Xorg:sh1 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4878 Xorg:sh2 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4879 Xorg:sh3 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4880 Xorg:sh4 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4881 Xorg:sh5 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4882 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4883 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4884 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4885 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 4873 4886 Xorg:gdrv diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5521 Xorg:cs0 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5522 Xorg:disk diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5523 Xorg:sh0 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5524 Xorg:sh1 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5525 Xorg:sh2 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5526 Xorg:sh3 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5527 Xorg:sh4 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5528 Xorg:sh5 diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5529 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5530 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5531 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5532 Xorg:shlo diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 Xorg 5520 5533 Xorg:gdrv diego mem REG 0,22 591624 438107 /usr/lib/libGL.so.1.7.0 $ pacman -Qo /usr/lib/libGL.so.1.7.0 /usr/lib/libGL.so.1.7.0 is owned by libglvnd 1.1.1-1 This is after I startx with LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH pointing to my mesa build.
I contacted Thomas Dickey (maintainer of xterm) and he said this about the issue: drivers, or Xorg in general - for instance the parts painting by XCopyArea (used by xterm and some other applications) may not be getting repainting-events https://lists.cairographics.org/archives/cairo/2015-May/026284.html or buggy acceleration features https://invisible-island.net/xterm/xterm.faq.html#compiz_bugs
I restarted the bisect and ended up at the same "bad commit": 6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit I wonder what I'm doing wrong...
If I do this: $ git revert -n 6328536ff28ca26f2ad4e6f2c956c467acebda88 $ git revert -n 621b0fa8922ade0a8122b868177308e65e6d3595 Then xterm works fine and I still have direct rendering.
Used clang to compile the latest mesa git master and it made no difference.
I just want to retract myself from saying these commits caused the problem for me, sorry about that. As suggested by MrCooper, I've compiled/installed mesa to /usr/local and added /usr/local/lib to /etc/ld.so.conf.d/mesa.conf to override the system mesa. We found that xterm still has the issue with Mesa 18.3.0.
We found quite a few things during our research: export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" This helps alleviate the problem (xterm does not have the issue with this), however, the problem is still present in Xephyr. We tested Xephyr from the current git master down to Xephyr from xserver 1.16 and the problem is also present, however, setting the following environment variable: export R600_DEBUG=nodpbb Makes the issue disappear entirely.
(In reply to Diego Viola from comment #62) > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > This helps alleviate the problem (xterm does not have the issue with this), > however, the problem is still present in Xephyr. To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps with current Xephyr, right? It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, otherwise primitives may be reordered across the barrier. Does that make sense, Marek?
(In reply to Michel Dänzer from comment #63) > (In reply to Diego Viola from comment #62) > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > > > This helps alleviate the problem (xterm does not have the issue with this), > > however, the problem is still present in Xephyr. > > To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make > use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps > with current Xephyr, right? Yes, that's correct. If I set `export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" ` before running `startx`, xterm works fine either in X or Xephyr (from git master). > > It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, > otherwise primitives may be reordered across the barrier. Does that make > sense, Marek?
Just to make it a bit more clear: If I set that environment variable while I'm already on X: export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" It has no effect on Xephyr (from current git master), i.e. xterm still shows the bug. However, if I set before `startx`. It works with both, X and Xephyr (from git master), i.e. xterm works fine.
(In reply to Diego Viola from comment #65) > Just to make it a bit more clear: > > If I set that environment variable while I'm already on X: > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > It has no effect on Xephyr (from current git master), i.e. xterm still shows > the bug. xterm still shows the bug in Xephyr from git if that environment was set later (while X was running). Works fine with both (Xephyr git and X) if the environment variable was set before startx. Please let me know if you have more questions.
(In reply to Michel Dänzer from comment #63) > (In reply to Diego Viola from comment #62) > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > > > This helps alleviate the problem (xterm does not have the issue with this), > > however, the problem is still present in Xephyr. > > To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make > use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps > with current Xephyr, right? > > It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, > otherwise primitives may be reordered across the barrier. Does that make > sense, Marek? Primitives aren't reordered with DPBB. Primitives can't also survive a barrier with DPBB. DPBB has no effect on behavior, it just changes how PS wavefronts are formed.
(In reply to Diego Viola from comment #65) > If I set that environment variable while I'm already on X: By "X" I assume you mean Xorg here? > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > It has no effect on Xephyr (from current git master), i.e. xterm still shows > the bug. Did you set the variable before starting Xephyr though, so it was set in the Xephyr process? If yes, that makes things confusing again, just when it seemed like they were starting to make sense...
(In reply to Marek Olšák from comment #67) > Primitives aren't reordered with DPBB. Primitives can't also survive a > barrier with DPBB. DPBB has no effect on behavior, it just changes how PS > wavefronts are formed. Is there any way that could affect the glamor shader which samples from one area of a buffer and draws to another (non-overlapping) area of the same buffer? What is the reason for radeonsi disabling DPBB for blits?
(In reply to Michel Dänzer from comment #68) > (In reply to Diego Viola from comment #65) > > If I set that environment variable while I'm already on X: > > By "X" I assume you mean Xorg here? Yes, Xorg.
(In reply to Michel Dänzer from comment #69) > (In reply to Marek Olšák from comment #67) > > Primitives aren't reordered with DPBB. Primitives can't also survive a > > barrier with DPBB. DPBB has no effect on behavior, it just changes how PS > > wavefronts are formed. > > Is there any way that could affect the glamor shader which samples from one > area of a buffer and draws to another (non-overlapping) area of the same > buffer? As long as the blits are truly non-overlapping, DPBB doesn't affect it. > > What is the reason for radeonsi disabling DPBB for blits? because it's not useful for blits and it might add latency because of binning.
(In reply to Michel Dänzer from comment #51) > The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, > so that makes sense? That was a mistake from my part, sorry. Setting 'export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"' after startx still makes xterm work fine even after startx (from a running Xorg session). Sorry for the confusion.
Sorry for the confusing comments. export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" makes xterm always work with Xpehyr git, no matter if I set that variable before or after startx.
(In reply to Diego Viola from comment #65) > Just to make it a bit more clear: > > If I set that environment variable while I'm already on X: > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > It has no effect on Xephyr (from current git master), i.e. xterm still shows > the bug. This comment is completely wrong, ignore it.
(In reply to Diego Viola from comment #72) > (In reply to Michel Dänzer from comment #51) > > The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, > > so that makes sense? > > That was a mistake from my part, sorry. > > Setting 'export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"' after > startx still makes xterm work fine even after startx (from a running Xorg > session). > > Sorry for the confusion. Replied to the wrong comment, this was supposed to be a reply to #68.
(In reply to Diego Viola from comment #24) > I've bisected the issue with the GTK elements sometimes disappearing, and > the commit that causes the issue is this one: > > 1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit Can you double-check this with Xephyr, taking everything we've learned since then into account, and if the same commit is identified again, file a new report about it?
(In reply to Michel Dänzer from comment #76) > (In reply to Diego Viola from comment #24) > > I've bisected the issue with the GTK elements sometimes disappearing, and > > the commit that causes the issue is this one: > > > > 1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit > > Can you double-check this with Xephyr, taking everything we've learned since > then into account, and if the same commit is identified again, file a new > report about it? Sure thing.
Created attachment 143956 [details] clinfo -A output
I found that a workaround for this issue is to add the following to my Xresources: XTerm.vt100.scaleHeight: 0.9 The default is 1.0 (which creates the problem), a value of 1.5 also makes it work (although fonts look too wide then). I found this information here: https://savannah.nongnu.org/bugs/index.php?52165 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407 Which might indicate this being a freetype problem?
(In reply to Diego Viola from comment #79) > Which might indicate this being a freetype problem? No. If it was a FreeType problem, R600_DEBUG=nodpbb or MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" couldn't work around it. Changing the xterm configuration just happens to avoid the problem somehow.
(In reply to Michel Dänzer from comment #80) > (In reply to Diego Viola from comment #79) > > Which might indicate this being a freetype problem? > > No. If it was a FreeType problem, R600_DEBUG=nodpbb or > MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" couldn't work around it. > > Changing the xterm configuration just happens to avoid the problem somehow. Makes sense, thanks.
I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but it still happens with -glamor.
(In reply to Diego Viola from comment #82) > I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but > it still happens with -glamor. Presumably the GL_NV_texture_barrier extension isn't available with GLES2, so this is the same as disabling that extension with OpenGL.
(In reply to Michel Dänzer from comment #83) > (In reply to Diego Viola from comment #82) > > I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but > > it still happens with -glamor. > > Presumably the GL_NV_texture_barrier extension isn't available with GLES2, > so this is the same as disabling that extension with OpenGL. Makes sense, thanks.
Created attachment 144054 [details] xterm exhibiting the bug xterm exhibiting the bug after running "dmesg" and hitting Shift+PgUp.
I found another workaround. Edit xterm's util.c and change line 2161: unsigned int h = (unsigned) (nlines * FontHeight(screen)); to: unsigned int h = (unsigned) (1000); i.e. increasing the h variable to a large enough number makes it work for some reason.
I have the same bug with xterm and shift+paging. Another similar bug. xfce4-terminal leaves a large black area at the bottom when it renders 'dmesg' or 'cat /etc/passwd'. AMD Ryzen 3 2200G. Arch Linux. Mesa 19.0.3-1
(In reply to komqinxit from comment #87) > Another similar bug. > xfce4-terminal leaves a large black area at the bottom when it renders > 'dmesg' or 'cat /etc/passwd'. > > AMD Ryzen 3 2200G. > Arch Linux. > Mesa 19.0.3-1 I can reproduce this, it happens for me with xfce4-terminal and also gnome-terminal and most other VTE-based terminals. I also noticed that setting R600_DEBUG=nodpbb and MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" does not seem to help.
Created attachment 144187 [details] Bug in Geany
Created attachment 144188 [details] Geany without a bug
xfce4-terminal and Geany bugs seem to be this https://bugs.freedesktop.org/show_bug.cgi?id=110355 and solved with mesa 19.0.4.
(In reply to komqinxit from comment #91) > xfce4-terminal and Geany bugs seem to be this > https://bugs.freedesktop.org/show_bug.cgi?id=110355 and solved with mesa > 19.0.4. That's good to know, thanks.
I just tried to reproduce this issue (xterm bug) with sway today and noticed that I can't reproduce it under sway. The bug can still be reproduced with weston and i3. - sway 1.0-8 - xorg-server-xwayland 1.20.4-1 - mesa 19.0.4-1
This bug is still present with mesa 19.1.0-1.
Still a problem with linux 5.2.0-arch2-1-ARCH and mesa 19.1.2-1.
Created attachment 144786 [details] Yet another workaround (patch) for xterm Replacing FontHeight for VDrawable seems to help.
s/for/with/
(In reply to Diego Viola from comment #96) > Created attachment 144786 [details] > Yet another workaround (patch) for xterm > > Replacing FontHeight for VDrawable seems to help. VDrawable is just a big number, so same thing as Comment 86. Nevermind.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes for DPBB, might help for this as well.
(In reply to Michel Dänzer from comment #99) > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes > for DPBB, might help for this as well. Unfortunately it doesn't help, I compiled mesa to /usr/local (from his dpbb_fixes branch) but the issue is still there.
Created attachment 144948 [details] comparison screenshot It looks like a DPBB/scissor interation issue. The screenshot on the left is a replay of a faulty trace with dpbb disabled. On the right the same trace, at the same point but using dpbb. The last executed commands are: glScissor(3, 3, 480, 144); glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, 1); As you can see, the purple area on the right doesn't honor the defined scissor area.
(In reply to Diego Viola from comment #100) > (In reply to Michel Dänzer from comment #99) > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes > > for DPBB, might help for this as well. > > Unfortunately it doesn't help, I compiled mesa to /usr/local (from his > dpbb_fixes branch) but the issue is still there. I just pushed a new commit on the same MR (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554/diffs?commit_id=d25df1274ea48fa73b0d8b31558e2cebb0851015). Could you test on your machine and let me know if it helps?
(In reply to Pierre-Eric Pelloux-Prayer from comment #102) > (In reply to Diego Viola from comment #100) > > (In reply to Michel Dänzer from comment #99) > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes > > > for DPBB, might help for this as well. > > > > Unfortunately it doesn't help, I compiled mesa to /usr/local (from his > > dpbb_fixes branch) but the issue is still there. > > I just pushed a new commit on the same MR > (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554/ > diffs?commit_id=d25df1274ea48fa73b0d8b31558e2cebb0851015). > > Could you test on your machine and let me know if it helps? I can confirm that your new commit fixes the problem. Thank you very much! :D
(In reply to Diego Viola from comment #103) > (In reply to Pierre-Eric Pelloux-Prayer from comment #102) > > (In reply to Diego Viola from comment #100) > > > (In reply to Michel Dänzer from comment #99) > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes > > > > for DPBB, might help for this as well. > > > > > > Unfortunately it doesn't help, I compiled mesa to /usr/local (from his > > > dpbb_fixes branch) but the issue is still there. > > > > I just pushed a new commit on the same MR > > (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554/ > > diffs?commit_id=d25df1274ea48fa73b0d8b31558e2cebb0851015). > > > > Could you test on your machine and let me know if it helps? > > I can confirm that your new commit fixes the problem. Thank you very much! :D Thanks for the confirmation. I added a Tested-by tag to the commit.
The commit fixing this issue has changed a bit, it would be great if you could confirm the latest version of the MR works well for you. Thanks!
(In reply to Pierre-Eric Pelloux-Prayer from comment #105) > The commit fixing this issue has changed a bit, it would be great if you > could confirm the latest version of the MR works well for you. > > Thanks! Yes, I can confirm it's working great with the latest version. Thank you!
The MR has been merged. Thanks again for reporting the bug and helping fixing it!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.