| Bug ID | 110214 |
|---|---|
| Summary | amdgpu: xterm scrollback buffer disappears while paging up/do= wn |
| Product | DRI |
| Version | XOrg git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | diego.viola@gmail.com |
Whenever I run `dmesg' on a xterm that uses the following opti= ons: xterm -fa "DejaVu Sans Mono:style=3DBook:antialias=3Dtrue" -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 opti= ons I mentioned above. Steps to reproduce: - run `xterm -fa "DejaVu Sans Mono:style=3DBook:antialias=3Dtrue"= -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 dr= iver and I can reproduce it with both, however, when setting Option "Accel&= quot; "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 xt= erm 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] R= aven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c6)
| What | Removed | Added |
|---|---|---|
| Product | DRI | Mesa |
| Component | DRM/AMDgpu | Drivers/Gallium/radeonsi |
| Version | XOrg git | 19.0 |
| QA Contact | dri-devel@lists.freedesktop.org |
Please attach the corresponding Xorg log file and output of gl= xinfo and dmesg. I can't seem to reproduce this, and I'm not sure what exactly "parts o= f 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 ke= rnel driver. Reassigning to Mesa for now, as glamor issues are no longer tracked here.
Created att=
achment 143749 [details]
Screencast demonstrating the problem
| What | Removed | Added |
|---|---|---|
| Hardware | Other | x86-64 (AMD64) |
| OS | All | Linux (All) |
(In reply to Michel D=C3=A4nzer from comment #1) > Please attach the corresponding Xorg log file an= d output of glxinfo and > dmesg. Done. >=20 > I can't seem to reproduce this, and I'm not sure what exactly "pa= rts of the > scrollback buffer disappear" means. Maybe you can make a screenca= st 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 ne= ed more info. Thanks.
(In reply to Diego Viola from comment #6) > (In reply to Michel D=C3=A4nzer from comment #1) > > Please attach the corresponding Xorg log file and output of glxin= fo and > > dmesg. >=20 > Done. >=20 > >=20 > > I can't seem to reproduce this, and I'm not sure what exactly &qu= ot;parts of the > > scrollback buffer disappear" means. Maybe you can make a scr= eencast or > > screenshots demonstrating the problem? >=20 > 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 scroll= bar. 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 al= so 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-disappea= rs-in-xterm
Tried mesa git (19.1.0-devel) with LLVM 9.0.0 (SVN) and the is= sue 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't reproduce the issue if I startx with LIBGL_ALWAYS_SOFT= WARE=3D1.
(In reply to Diego Viola from comment #14) > I can't reproduce the issue if I startx with LIB= GL_ALWAYS_SOFTWARE=3D1. How exactly did you set that? Normally, I'd expect it to only affect client= s, not the X server. Are you using a compositing manager?
(In reply to Michel D=C3=A4nzer from comment #15) > (In reply to Diego Viola from comment #14) > > I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWAR= E=3D1. >=20 > How exactly did you set that? Normally, I'd expect it to only affect > clients, not the X server. >=20 > Are you using a compositing manager? In my TT1: export LIBGL_ALWAYS_SOFTWARE=3D1 then startx after that. When I'm on X, I open an xterm and LIBGL_ALWAYS_SOFTWARE=3D1 will be set, g= lxinfo also reports llvmpipe. I'm using i3-wm, no I don't use a compositing manager.
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=C3=A4nzer from comment #19) > (In reply to Diego Viola from comment #12) > > I also tried recompiling xorg-server (git and 1.20.0) and the pro= blem still > > persists with those, [...] >=20 > Did you build xserver with meson or autotools? autotools