Regression: block staircase display with side-by-side monitors of different pixel widths

Bug #1873895 reported by TJ on 2020-04-20
This bug affects 10 people
Affects Status Importance Assigned to Milestone
libxcb (Ubuntu)
xfwm4 (Ubuntu)
xserver-xorg-video-amdgpu (Ubuntu)

Bug Description

Update based on further research.

This only happens when the secondary external display is operating at a different pixel width to the internal. In this case eDP is 1920x1080 whereas the external HDMI-A-0 is natively 1680x1050.

It is caused by xfwm4's recent switch from using glx to xpresent for AMD GPUs.

The underlying bug is in the AMD driver.

I was able to reproduce on an external 1920x1200 display only when it was set to a non-native 1680x1050 resolution.

Two identical Lenovo E495 laptops with 20.04 installed. The problem occurred initially on the laptop that is having package upgrades applied regularly.

With dual monitors and the external monitor placed left or right the display has a blocked staircase effect shown in the attached photograph, and seems related to

More detailed investigation suggests it only happens when the X coordinate of the two monitors is different. The symptom looks like an off-by-one error because it appears as if the display is divided into, say, 10 rows and 15 columns but the first row has 16 'columns' worth of blocks on it and so wraps to the beginning of the 2nd row, and so on.

On the laptop without package upgrades being applied this didn't happen. So I upgraded it (314 packages) and restarted and it too sees the same problem.

I suspected libxcomposite1 and downgraded it to 1:0.4.5-0ubuntu1 but that didn't solve it.

I now suspect libxcb but so far haven't been able to prove it.
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: XFCE
DistUpgraded: Fresh install
DistroCodename: focal
DistroRelease: Ubuntu 20.04
DistroVariant: ubuntu
 Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c1) (prog-if 00 [VGA controller])
   Subsystem: Lenovo ThinkPad E595 [17aa:5124]
InstallationDate: Installed on 2020-04-08 (11 days ago)
InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200408)
MachineType: LENOVO 20NECTO1WW
Package: xserver-xorg-video-amdgpu 19.1.0-1
PackageArchitecture: amd64
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-21-generic root=/dev/mapper/ELLOE000-rootfs ro acpi_osi=! "acpi_osi=Windows 2016" quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Tags: focal ubuntu ubuntu
Uname: Linux 5.4.0-21-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lp lpadmin lxd plugdev sambashare sudo users
_MarkForUpload: True 12/23/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: R11ET32W (1.12 )
dmi.board.asset.tag: Not Available 20NECTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR11ET32W(1.12):bd12/23/2019:svnLENOVO:pn20NECTO1WW:pvrThinkPadE495:rvnLENOVO:rn20NECTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone: ThinkPad E495 20NECTO1WW
dmi.product.sku: LENOVO_MT_20NE_BU_Think_FM_ThinkPad E495
dmi.product.version: ThinkPad E495
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

TJ (tj) wrote :
TJ (tj) wrote :

The packages upgraded on the second laptop that are libx related are:

$ grep 'Upgrade: hunspell' /var/log/apt/history.log | grep -o 'libx[^ ]*'

TJ (tj) wrote :

I'm attaching the complete list of packages upgraded on the second laptop that triggered this bug.

The total list is over 300 packages. I've prefixed the unlikely package with #. That leaves 77 possibles all related to X server or display drivers.

TJ (tj) wrote :

These are the packages I've tested via a downgrade:

$ apt list --upgradeable
Listing... Done
libxcomposite1/focal 1:0.4.5-1 amd64 [upgradable from: 1:0.4.5-0ubuntu1]
libxcomposite1/focal 1:0.4.5-1 i386 [upgradable from: 1:0.4.5-0ubuntu1]
libxdamage1/focal 1:1.1.5-2 amd64 [upgradable from: 1:1.1.5-1]
libxdamage1/focal 1:1.1.5-2 i386 [upgradable from: 1:1.1.5-1]
libxfixes3/focal 1:5.0.3-2 amd64 [upgradable from: 1:5.0.3-1]
libxfixes3/focal 1:5.0.3-2 i386 [upgradable from: 1:5.0.3-1]
linux-generic/focal amd64 [upgradable from:]
linux-headers-generic/focal amd64 [upgradable from:]
linux-image-generic/focal amd64 [upgradable from:] 0.99-0ubuntu1 amd64 [upgradable from: 0.98-0ubuntu4]

Timo Aaltonen (tjaalton) wrote :

as you can see we already had the upstream versions of those libs, so they didn't break it

TJ (tj) wrote : CurrentDmesg.txt

apport information

tags: added: apport-collected focal ubuntu
description: updated
TJ (tj) wrote : Dependencies.txt

apport information

TJ (tj) wrote : DpkgLog.txt

apport information

TJ (tj) wrote : LightdmDisplayLog.txt

apport information

TJ (tj) wrote : LightdmLog.txt

apport information

TJ (tj) wrote : Lspci.txt

apport information

TJ (tj) wrote : Lspci-vt.txt

apport information

TJ (tj) wrote : Lsusb.txt

apport information

TJ (tj) wrote : Lsusb-t.txt

apport information

TJ (tj) wrote : Lsusb-v.txt

apport information

TJ (tj) wrote : ProcCpuinfo.txt

apport information

apport information

TJ (tj) wrote : ProcEnviron.txt

apport information

TJ (tj) wrote : ProcInterrupts.txt

apport information

TJ (tj) wrote : ProcModules.txt

apport information

TJ (tj) wrote : UdevDb.txt

apport information

TJ (tj) wrote : XorgLog.txt

apport information

TJ (tj) wrote : XorgLogOld.txt

apport information

TJ (tj) wrote : Xrandr.txt

apport information

TJ (tj) wrote : xdpyinfo.txt

apport information

Timo: yes, sorry, I think I got a bit confused about packages due to lack of sleep. I've reported this against xserver-xorg-video-amdgpu for now although looking at the apt history it wasn't updated.

I'm not too familiar with the Xorg internals so any pointers on potential culprits would be welcome to narrow this down.

We have 6 of these Lenovo E495 laptops all seeing the same issue.

Originally I suspect the kernel since the first affected PC was on -25 whilst the 2nd was on -21 but booted with -21 and still affected. That was when we started looking at what packages had upgraded on the 1st PC and, later, when we realised 2nd PC was unaffected did a package upgrade on that (the 300+) and it was then affected.

Must be something in one of those packages.

TJ (tj) wrote :

Reproducing this:

$ xrandr -d :0.0 --output HDMI-A-0 --left-of eDP
$ xrandr -d :0.0 --output HDMI-A-0 --right-of eDP

No problem with:

$ xrandr -d :0.0 --output HDMI-A-0 --above eDP
$ xrandr -d :0.0 --output HDMI-A-0 --below eDP

The affected and unaffected laptops each have identical kernel log entries about IRQ 7 and SADs count so I don't think those are related to this.

TJ (tj) wrote :

With the help and suggestions of Bluesabre on #xubuntu-devel we've tracked it down to a recent change in xfwm4 where it switched from using glx to xpresent:

which seems to be a bug in the driver as mentioned orginally:


It is also SPECIFIC to the resolution selected on the external HDMI display.

In our case the Lenovo E495 has eDP 1920x1080 and external HDMI are 168x1050 and are affected.

I tried with another external HDMI that is natively 1920x1200 and couldn't reproduce UNTIL I set it to use 1680x1050 instead of its preferred resolution, at which point the blocked staircase returned.

As I said above it feels like an off-by-one bug on the assumption rendering the display is split into regions (columns) and it is rendering 1920 pixels to a 1680 wide output with the pixels 1680-1919 wrapping to the next 'row'.

TJ (tj) wrote :

Urgh, should have written "With the help and suggestions of 'brainwash' and 'bluesabre' on #xubuntu-devel..."

summary: - Regression: block staircase display with side-by-side monitors
+ Regression: block staircase display with side-by-side monitors of
+ different pixel widths
description: updated
TJ (tj) wrote :

I've worked with upstream AMD and we've fixed the problem in in xf86-video-amdgpu. As soon as that is available in the upstream repository I'll prepare a cherry-pick update to 20.04.

I suspect we also need to consider an SRU patch to 18.04 ?

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libxcb (Ubuntu):
status: New → Confirmed
Changed in xfwm4 (Ubuntu):
status: New → Confirmed
Changed in xserver-xorg-video-amdgpu (Ubuntu):
status: New → Confirmed
Jim Carpenter (jim02762) wrote :

Just tried upgrading my Xubuntu 19.10 desktop to 20.04 and I'm now getting the same staircase effect. Video card is an AMD Radeon RX 5700 XT which is connected with a DisplayPort -> DVI-D cable to an ancient LG W2252TQ monitor with a resolution of, yes, 1680x1050. It is the only monitor connected.

Just thought I'd share. Rolling back to 19.10 now. I'll try again with the point release.

bjo (bjo81) wrote :

You can simply switch back to glx:

xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "glx" --create

until the issue is fixed in the driver. Then you can set it back to "auto".
No need to roll back.

I have similar problem with xubuntu & ubuntu studio (fresh install or upgrade) ,
it happen only with some resolutions & without screen rotation.
 i "solved" it increasing framebuffer in at least 1 pixel,

eg: xrandr --fb 1441x900 --output DisplayPort-0 --mode 1440x900 --panning 1440x0


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.