Characters are rendered with a slight border when using custom xrandr scaling

[Ethan Blanton]

I frequently get screen corruption or delayed screen updates using onboard Intel video (i7-10710U in a Dell XPS 13 7390). I am attaching a screen shot of an example of this in Emacs, where you can see echoes of past cursor locations (center right side of screen, the highlighted word "boolean").

A frequent failure is that an application updates its window, but the updates do not appear on screen until I take some action to disturb the window (move or resize it, change focus, change desktops, etc.), after which it cleans itself up. Small changes (such as selecting text) will often clean up the image where the change is made without repainting the entire window.

My display panel is 4K UHD+, and I have attached two external Full HD DisplayPort monitors using chaining with 2x2 scale using XrandR. This corruption appears to happen on all three surfaces. The configuration for my desktop is:

HIX=3840
HIY=2160
HI=${HIX}x${HIY}
xrandr --fb $(($HIX * 3))x$HIY \
       --output eDP-1 --auto --panning ${HI}+$(($HIX * 2))+0 \
       --output DP-2-8 --auto --panning ${HI}+$HIX+0 \
                       --scale-from $HI --left-of eDP-1 --scale 2x2 \
       --output DP-2-1 --auto --panning $HI+0+0 \
                       --scale-from $HI --left-of DP-2-8 --scale 2x2

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop:

Date: Wed Sep 2 11:48:03 2020
DistUpgraded: 2020-06-21 15:36:52,619 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
DistroCodename: focal
DistroVariant: ubuntu
DkmsStatus: v4l2loopback, 0.12.3, 5.4.0-42-generic, x86_64: installed
DpkgLog:

ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation Device [8086:9bca] (rev 04) (prog-if 00 [VGA controller])
   Subsystem: Dell Device [1028:0962]
MachineType: Dell Inc. XPS 13 7390
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-42-generic root=UUID=aeb9197c-491f-493d-9a7a-7094efd5023c ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to focal on 2020-06-21 (72 days ago)
dmi.bios.date: 11/25/2019
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.4.0
dmi.board.name: 0377MH
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.4.0:bd11/25/2019:svnDellInc.:pnXPS137390:pvr:rvnDellInc.:rn0377MH:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 7390
dmi.product.sku: 0962
dmi.sys.vendor: Dell Inc.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.2
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

[Daniel van Vugt (vanvugt)]

I can't see a problem in that screenshot or the logs. Maybe consider attaching a video instead?

Also please tell us if the problem happens:

 * Without your custom xrandr commands

 * In a Wayland session (select 'Ubuntu on Wayland') from the login screen after selecting your username.

[Ethan Blanton (eblanton)]

The specific part of the screen shot with obvious corruption is cropped below. I'll try to get a video; one problem I have is that many of the specific things I do that reliably show the problem are at times when private data is visible on my screen.

I _cannot_ show this problem without the XrandR command (or some GUI-configured equivalent), because it seems to only happen with external DisplayPort monitors attached. When I use _only_ the internal laptop panel things appear to work correctly (or did last time I checked, I very seldom run only one display). I believe the problem is triggered by either 1) daisy-chained DisplayPort monitors or 2) the sheer size of my desktop (11520x2160).

I will try to find something that reliably corrupts that is not sensitive to get a video, and I will test with no external displays attached and verify that that is still error-free.

[Daniel van Vugt (vanvugt)]

Thanks for the screenshot. It's hard to tell if that's a bug in the application, the toolkit, Xorg or the compositor.

Please continue collecting more screenshots of the problem. Please also try a different desktop environment that's not GNOME. If your xrandr command triggers the same problem without GNOME then we don't need to involve the 'mutter' package in this bug.

[Ethan Blanton (eblanton)]

It happens for sure in the following applications (which I think rules out the application and toolkit, but not the compositor or Xorg):

* Firefox
* Emacs
* Electron apps (Keybase, Slack, Element)
* Okular
* OBS (maybe; this may be a different problem)
* FreeCAD (maybe; FreeCAD has painting problems in general)
* VMware (both the UI and the guest)

Interestingly, I don't think I have seen any misbehavior in urxvt, which I use a lot.

I am not using GNOME. My window manager is awesome and my compositor is compton. The mutter package is not installed on this machine.

I will try to get more screen shots, although this is hard to capture because disturbing the window often causes a repaint. I have tried to capture video a few times, but as I am working with private information that does not belong to me on this machine I haven't yet captured an instance where there was nothing on my screen I am unable to share.

[Daniel van Vugt (vanvugt)]

In my experience the kind of corruption shown in comment #3 can only happen with X11 compositors. Because only X11 allows apps to defer responsibility for placing parts of the app (like characters in an editor) to a separate compositor.

So this is probably a bug in compton. Less likely a bug in Xorg.

[Ethan Blanton (eblanton)]

I have disabled compton as follows:

* Quit Firefox and other applications that have shown these problems
* Kill compton
* Restart applications

Unfortunately, I still see the same behavior, in just a few seconds of tinkering. I'll leave compton off until I have to start it (e.g., for Zoom, which won't run without a compositor) and see if I can get another screen shot.

If that is not a suitable method to rule out compton as the culprit, please let me know how I should do so. (But it seems to me that if it is not running, it's probably not the problem.)

[Ethan Blanton (eblanton)]

This video shows litter at the cursor when using Swiper for Emacs search. Note near the top left of the screen, while the search string "bitwise" is being typed in at the bottom, that the first match (the word Bitwise in \subtitle{Bitwise Operations}) does not correctly repaint, with echoes of the cursor being left behind as it moves across the word.

This is the Ubuntu-installed Emacs 1:26.3+1-1ubuntu2, using Swiper installed from ELPA; however, this sort of corruption shows up in a variety of cases in Emacs (this is just the most reliable method I know to trigger it).

Compton is NOT running in this test. Xorg is modesetting. Kernel is 5.4.0-42-generic.

Firefox just glitched significantly while looking up how to reliably determine my Xorg server module, I will upload a video of that, as well.

[Ethan Blanton (eblanton)]

This video is taken under the same conditions as the previous (emacs-search.mp4) video. It shows me killing a Firefox tab, and the screen covered in litter; as I edit in the Launchpad comment box and move the cursor within firefox, you can see parts of the screen repaint. The entire window does not repaint until I move the cursor to focus another window (off-screen to the right).

Again, compton not running, Xorg modesetting server 2:1.20.8-2ubuntu2.4, Linux 5.4.0-42-generic.

[Ethan Blanton (eblanton)]

I have other problems that I assume are related but may not be the same bug, so I did not report them here; for the record (in case it helps), they include:

* OBS will not repaint its preview window _at all_ and sometimes hangs UNLESS I move it to my leftmost display (DP-2-1) _and resize it_. After doing this, it is reliable and works normally on ANY display. If I don't do this, it doesn't repaint at all on any display. The UI works fine, but the video overlay (via whatever method it uses) for the preview window just shows a gray box that sometimes takes on corruption.

* Electron apps run fine on DP-2-1 and DP-2-8, but if I move them to eDP-1 (located at the far right, the only unscaled panel running 3840x2160) they are _extremely_ slow to draw. Typing in the window, the characters take up to several seconds to show up on screen, and clicks take seconds to register. This is visible in Slack, Discord, Keybase, and Element. Disabling GPU acceleration (either via the app preference in Slack, or the Electron option --disable-gpu for others) causes them to run normally, with no lag.

* OpenGL applications _in general_ run terribly on eDP-1; with vblank_mode=0, maximized glxgears runs over 400 fps on DP-2-1 and DP-2-8, but under 100 on eDP-1. I have seen it run as few as ~15 FPS on eDP-1 but am not seeing that currently; that may be related to other factors?

* Video playback is noticeably jerky sometimes, appearing to skip or jitter frames. I have not noticed whether it matters which display I am using when this happens. Sometimes I don't notice it, sometimes it seems pretty bad. This is visible using mplayer or watching YouTube in Firefox. This is a subjective point, I cannot _measure_ the frame drops (or at least, I don't know how).

[Daniel van Vugt (vanvugt)]

Comment #8 looks like the same bug, which I would now assign to either emacs or xorg-server.

Comment #9 looks like a different bug so let's not discuss that here. Each problem should have a separate bug report.

[Ethan Blanton (eblanton)]

I will open a second bug for comment #9, then.

Regarding #8 and Emacs; I am running exactly the same Emacs with exactly the same configuration (the configurations are both checkouts of exactly the same Mercurial repository) on three different machines. This is the only machine that displays that behavior (and it also has _numerous_ other display problems, as described above).

[Ethan Blanton (eblanton)]

I just filed #1898210 for comment #9.

Note for the record that the Emacs behavior is _exactly the same_ as Firefox, and is not _always_ related to the cursor. In particular, changing window focus causes it to redraw correctly without fail.

[Ethan Blanton (eblanton)]

The emacs rendering bugs go away with this RandR configuration:

xrandr --fb $((1920 * 3))x1080 --dpi 100 \
       --output eDP-1 --mode 1920x1080 \
       --output DP-2-8 --auto --left-of eDP-1 \
       --output DP-2-1 --auto --left-of DP-2-8