https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #2 from Diego Viola diego.viola@gmail.com --- Created attachment 143749 --> https://bugs.freedesktop.org/attachment.cgi?id=143749&action=edit Screencast demonstrating the problem

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #4 from Diego Viola diego.viola@gmail.com --- Created attachment 143751 --> https://bugs.freedesktop.org/attachment.cgi?id=143751&action=edit glxinfo

https://bugs.freedesktop.org/show_bug.cgi?id=110214

Diego Viola diego.viola@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86-64 (AMD64) OS|All |Linux (All)

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #7 from Diego Viola diego.viola@gmail.com --- (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).

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #9 from Diego Viola diego.viola@gmail.com --- I also get the same issue if I run xterm from sway/weston (via xwayland).

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #11 from Diego Viola diego.viola@gmail.com --- Tried mesa git (19.1.0-devel) with LLVM 9.0.0 (SVN) and the issue still persists.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #13 from Diego Viola diego.viola@gmail.com --- I can also reproduce the issue with Xephyr -glamor.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #15 from Michel Dänzer michel@daenzer.net --- (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?

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #17 from Diego Viola diego.viola@gmail.com --- TTY1, sorry.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #19 from Michel Dänzer michel@daenzer.net --- (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?

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #21 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #23 from Diego Viola diego.viola@gmail.com --- When starting X with LIBGL_ALWAYS_SOFTWARE=1 the rendering issues with GIMP also goes away.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #25 from Michel Dänzer michel@daenzer.net --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #26 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #28 from Diego Viola diego.viola@gmail.com --- I guess I'll need to install mesa system wide to be really sure, I'll do that and confirm.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #30 from Diego Viola diego.viola@gmail.com --- 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

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #32 from Michel Dänzer michel@daenzer.net --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #34 from Diego Viola diego.viola@gmail.com --- Created attachment 143830 --> https://bugs.freedesktop.org/attachment.cgi?id=143830&action=edit glxinfo from Ubuntu 18.04.2

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #36 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #38 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #40 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #42 from Diego Viola diego.viola@gmail.com --- Created attachment 143832 --> https://bugs.freedesktop.org/attachment.cgi?id=143832&action=edit git bisect log

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #44 from Diego Viola diego.viola@gmail.com --- (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?

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #46 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #48 from Diego Viola diego.viola@gmail.com --- Created attachment 143834 --> https://bugs.freedesktop.org/attachment.cgi?id=143834&action=edit 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).

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #50 from Diego Viola diego.viola@gmail.com --- I can reproduce the issue with apitrace on Ubuntu 19.04.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #52 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #54 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #56 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #58 from Diego Viola diego.viola@gmail.com --- 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...

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #60 from Diego Viola diego.viola@gmail.com --- Used clang to compile the latest mesa git master and it made no difference.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #61 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

Michel Dänzer michel@daenzer.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Version|19.0 |git

--- Comment #63 from Michel Dänzer michel@daenzer.net --- (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?

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #65 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #67 from Marek Olšák maraeo@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #69 from Michel Dänzer michel@daenzer.net --- (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?

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #71 from Marek Olšák maraeo@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #73 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #75 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #77 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #78 from Diego Viola diego.viola@gmail.com --- Created attachment 143956 --> https://bugs.freedesktop.org/attachment.cgi?id=143956&action=edit clinfo -A output

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #80 from Michel Dänzer michel@daenzer.net --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #82 from Diego Viola diego.viola@gmail.com --- I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but it still happens with -glamor.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #84 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #86 from Diego Viola diego.viola@gmail.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #88 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #90 from komqinxit@zoho.eu --- Created attachment 144188 --> https://bugs.freedesktop.org/attachment.cgi?id=144188&action=edit Geany without a bug

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #92 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #94 from Diego Viola diego.viola@gmail.com --- This bug is still present with mesa 19.1.0-1.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #96 from Diego Viola diego.viola@gmail.com --- Created attachment 144786 --> https://bugs.freedesktop.org/attachment.cgi?id=144786&action=edit Yet another workaround (patch) for xterm

Replacing FontHeight for VDrawable seems to help.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #98 from Diego Viola diego.viola@gmail.com --- (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://bugs.freedesktop.org/show_bug.cgi?id=110214

Diego Viola diego.viola@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|Raven Ridge: xterm |Raven Ridge (2400G): xterm |scrollback buffer |scrollback buffer |disappears while Shift+PgUp |disappears while Shift+PgUp |and Shift+PgDn |and Shift+PgDn

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #100 from Diego Viola diego.viola@gmail.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #102 from Pierre-Eric Pelloux-Prayer pierre-eric.pelloux-prayer@amd.com --- (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...).

Could you test on your machine and let me know if it helps?

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #104 from Pierre-Eric Pelloux-Prayer pierre-eric.pelloux-prayer@amd.com --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

--- Comment #106 from Diego Viola diego.viola@gmail.com --- (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!