(Linux & X11) Extremely slow windows when laptop display is disabled.

[willmtemple]

When I turn my laptop display off, my displaylink monitors become extremely slow.

Monitors work fine and have no obvious performance issues when connected to my laptop. However, attempting to disable the laptop display (regardless of whether or not the lid is closed -- closing the lid doesn't cause any problems as long as the display has a mode in xrandr), results in extremely slow changes to windows. The cursor seems to move only a little bit slower than before, but windows repaint extremely slowly (measured exactly 1.000 FPS using glxgears).

I'd really like to just plug my laptop in at work and close the lid, making my first DisplayLink monitor primary, and I don't want to have to buy a Thunderbolt dock if I don't have to.

Software and System

Lenovo ThinkPad T440s w/ Lenovo Hybrid USB-C Dock. Arch Linux.

• Linux 5.4.11
• Xorg 1.20.6
• displaylink 5.2.14
• evdi 1.6.4-2

$ modinfo evdi
filename:       /lib/modules/5.4.11-arch1-1/kernel/drivers/gpu/drm/evdi/evdi.ko.xz
license:        GPL
description:    Extensible Virtual Display Interface
author:         DisplayLink (UK) Ltd.
srcversion:     4F284B13CC5D2D97950EA33
depends:        drm,drm_kms_helper,syscopyarea,sysfillrect,sysimgblt
retpoline:      Y
name:           evdi
vermagic:       5.4.11-arch1-1 SMP preempt mod_unload
parm:           initial_loglevel:Initial log level (int)
parm:           initial_device_count:Initial DRM device count (default: 0) (ushort)
parm:           enable_cursor_blending:Enables cursor compositing on user supplied framebuffer via EVDI_GRABPIX ioctl (default: true) (bool)

Steps to reproduce:

0. Use linux
1. Attach a displaylink monitor to your laptop
2. configure an X screen with the evdi device (I usually use arandr)
3. disable the laptop screen, something like xrandr --output eDP-1 --off
4. observe exactly 1 frame every 1 second

[willmtemple]

This seems like it's related to OpenGL performance. Disabling my window compositor (picom) causes the UI to become responsive again, but some OpenGL contexts (glxgears) remain slow, still exactly 1.000 FPS.

[mfdgroot]

I can confirm this problem on Fedora 31.
I checked my dnf history and traced it back to either gnome-session to 3.34.2-1 or xorg-x11-server-Xorg to 1.20.6-1.

[rprihoda]

I had this problem with a fresh install of Fedora 30. @mfdgroot I noticed your comment and check my packages. I am running an earlier version of gnome-session (3.32.0-1) so that could not be the problem. We were running the same version of xorg-x11-server though. So I decided to run
dnf downgrade xorg-x11-server*
which downgraded
xorg-x11-server-Xephyr.x86_64 xorg-x11-server-Xorg.x86_64 xorg-x11-server-Xwayland.x86_64 xorg-x11-server-common.x86_64 xorg-x11-server-utils.x86_64
to version 1.20.4-3.fc30 and now the problem is gone.

I don't know in which package the problem lies but I am happy I can close my lid now.

[kugel-]

I can confirm this on Arch Linux (bad latency (1s sounds about right) as well as the effective workaround of enabling the laptop display). This has been working before so I suspect @rprihoda on the right track. I haven't confirmed myself though.

[kugel-]

I can now confirm too that downgrading xserver helps. To be precise, I downgraded xorg-server and xorg-serer-common to 1.20.5 from Arch Rollback Machine (https://archive.archlinux.org/packages/x/xorg-server/ and https://archive.archlinux.org/packages/x/xorg-server-common/

Here's the 1.20.6 release announcement: https://lists.x.org/archives/xorg-announce/2019-November/003032.html in case anyone has a clue.

[kugel-]

I suspect it relates to the newly added "GLX vendor selection support". Looking at the relevant code, it seems the GLX vendor can now be set per-screen, and I guess we now have a different vendor if only the DisplayLink screen is active (compared to both DisplayLink and laptop screen). I don't know how to further debug this, though, or how to verify the GLX vendor.

glxinfo gives the same in both scenarios:

$ glxinfo | grep vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
OpenGL vendor string: Intel Open Source Technology Center

[mfdgroot]

@kugel- Thanks for confirming. The problem should indeed be somewhere in that changelog.

I doubt that it has to do with the vendor.
There's no reference to it anywhere in the evdi code.
And as far as I can see it is per Linux "DISPLAY" and all your screens are bunched under 1 display with name ":0"
Only when you really make a different display object, you will be dealing with this code. But that's not what's happening with multiple screens. They are treated as one display, so it's also not surprising that laptop lid open or closed show up as the same string.

I bet my money on the modesetting changes that involve the master and slave screen. Sadly I also don't have the technical skills to actually fix this.

[Zetabite]

can confirm the issue on latest displaylink and evdi on arch/manjaro on kernel 5.4

[kugel-]

xserver 1.20.8 is released, did anyone check if it's still problematic? My dock setup is at work, not going there due to Corona virus atm.

[aremai]

thankfully I have finally found a thread that describes exactly my problem.

i'm currently running arch with the following setup, and I can confirm those annoying delays (a couple of seconds delay between switching windows/applications):

laptop: dell xps13
docking station: dell d3000 (connected over HDMI)

arch linux:

• kernel: 5.4.30-1-lts
• displaylink: 5.2.14-1
• evdi: 1.6.4-2
• xserver: 1.20.8-1

drivers installed (not sure if both are necessary, but installed them at some point because i needed them):

• intel: xf86-video-intel 1:2.99.917+899+gf66d3954-1
• vesa: xf86-video-vesa 2.4.0-2

Current config in /etc/X11/xorg.conf.d/20-displaylink.conf

Section "Device"
 Identifier "DisplayLink"
 Driver "modesetting"
 Option "PageFlip" "false"
EndSection

The switching between applications is very very slow, and takes a couple of seconds. Usually this was pretty swift, just a couple of miliseconds, nothing worth mentioning.

Any ideas what could be causing this slowness/delays?
Any particular logs that would be worth looking into?

I'd appreciate any advice on how to debug this......it's driving me insane.
Thanks for the workaround with the enabled laptop display. This seems to do the trick for me (for now).

Maybe this also helps:

filename:       /lib/modules/5.4.30-1-lts/kernel/drivers/gpu/drm/evdi/evdi.ko.xz
license:        GPL
description:    Extensible Virtual Display Interface
author:         DisplayLink (UK) Ltd.
srcversion:     4F284B13CC5D2D97950EA33
depends:        drm,drm_kms_helper,syscopyarea,sysfillrect,sysimgblt
retpoline:      Y
name:           evdi
vermagic:       5.4.30-1-lts SMP mod_unload 
parm:           initial_loglevel:Initial log level (int)
parm:           initial_device_count:Initial DRM device count (default: 0) (ushort)
parm:           enable_cursor_blending:Enables cursor compositing on user supplied framebuffer via EVDI_GRABPIX ioctl (default: true) (bool)

[aremai]

Any news on this?

[Gal-Zaidman]

Seeing the same thing on fedora 31, with latest evdi.
I have:
xorg-x11-server-* 1.20.5-7.fc31
and
gnome-session. 3.34.2-2.fc31

[richardnpaul]

Yup, Ubuntu 20.04 here, just the standard kernel, xorg, wayland. DisplayLink is the latest version from the website, 5.3.1.34, so whichever version of EVDI comes with that (srcversion: 5EAC17D8E38A4BDB48B7503).

I had this issue on upgrading the DisplayLink driver once I upgraded to 20.04 where it was unusable under Xorg because of the reported latency/lag/low FR as I too have two displays and close my laptop lid as my usual usage. However, Xorg was my default because in a previous Ubuntu upgrade Wayland wasn't usable for me (I have Intel/Nvidia PRIME laptop but mainly just use the iGPU these days) but enabling Wayland again under 20.04 and using that has given me a passably usable desktop (still with occasional stuttering with the laptop display closed but only for fractions of a second).

[eyalmazuz]

same problem here:
Dell Xps 15 7590
distro: Ubuntu 20.04
kernel: 5.4.0-31
Xorg: 1.20.8-2
displaylink: 5.3.1
evdi: 1.6

[stiobhan]

Same problem here

Ubuntu 20.04
kernel: 5.4.0-33-generic, x86_64
Xorg: 1.20.8 (2:1.20.8-2ubuntu2.1)
displaylink: 5.3.1
evdi: 1.7.0

[KevinFiorentino]

It didn't work here.
Ubuntu 20.04
displaylink: 5.3.1
Kernel: 5.4.0-33-generic, x86_64

Please, one solution. Thanks!

[displaylink-dkurek]

Please take a look at
https://www.displaylink.org/forum/showthread.php?t=67148

In short, we have raised the issue in Xserver issue tracker https://gitlab.freedesktop.org/xorg/xserver/-/issues/1028
and there is open (at the time beeing) MR with a fix
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/448

[stiobhan]

Big thanks for providing the patched Xserver package! I'll test it and give feedback later this week when I have access to my docking station again.

[mohitt]

This issue exists even on ubuntu 18.04 , xserver-xorg-core version 2:1.20.8-2ubuntu2.1~18.04.1.

@displaylink-dkurek can you please provide the xserver package for 18.04.1 LTS as well. I tried the 20.04 package. It throws an error while installing

[elcuervo]

Came here for the exact same thing. Also in 18.04 without a compatible fix

[mohitt]

@elcuervo JakubDabrowski from customer support team released the package for displaylink. I have requested him to release a ptach for 18.04 here https://www.displaylink.org/forum/member.php?u=20834

[deltreey]

I'm on 20.04 (preinstalled) on an XPS 13 through a d3100 and I'm having this exact issue. So I should be the perfect test dummy here because I'm running a dell linux laptop on a dell docking station. This is me offering to be a guinea pig.

NOTE: enabling my laptop display COMPLETELY fixes the problem, which is really weird. My laptop display doesn't even have to be the primary monitor.

[galindro]

I can confirm that the X.org xserver patch released by Displaylink as a workaround for this issue works pretty well. Here is the link to download it: https://www.displaylink.org/forum/showthread.php?t=67148. Don't forget to reboot your machine after apply it.

I'm using KDE Neon 5.19 based on Ubuntu 20.04. I got this problem yesterday when I upgraded from Ubuntu 18.04 to 20.04.

Tks Displaylink.

[displaylink-dkurek]

There are quite old issue and MR on xorg regarding this:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1028
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/460
Closing this issue :)

[rileyrg]

Debian 11 same issue.

[ceymard]

Same with ubuntu 21.04

[JavierBejMen]

Same with archlinux

[Leigh-M]

Same with 21.04, Dell Precision 7530 (no DisplayLink) just close laptop lid and use just external monitors, system becomes slow & unusable. Open laptop lid works normally right away

[SilvestreCasagrande]

Instead of desactivating the built in monitor what I did is mirror my laptop desktop to monitor on the left with

xrandr --output eDP --same-as DVI-I-2-2
eDP = built in monitor
DVI-I-2-2 = left monitor

and extende the build in monitor to my right monitor with

xrandr --auto --output DVI-I-1-1 --mode 1920x1080 --right-of eDP
DVI-I-1-1 = right monitor

to know your monitors type: xrandr built in monitor will apear as Screen 0

hope it helps for the ones like me that didn't get the problem solve by downgrading xserver-xorg-core

just make sure your laptop dont sleep when closing the lid and your are done.

[kfirfer]

Same on ubuntu 21.10

[faysalnadim]

After countless hours and different workarounds I switched to Wayland instead. The problem was gone, much smoother and pleasant experience so far. Finally able to dock my machine.

[Leigh-M]

@faysalnadim what distro/ version/ kernel are you running and is there a link for correct way to install/ switch to Wayland? Thanks

[yinrong]

Select wayland upon login, desktop freezes.

Ubuntu 21.10
Nvidia
Nouveau on/off

After countless hours and different workarounds I switched to Wayland instead. The problem was gone, much smoother and pleasant experience so far. Finally able to dock my machine.

[delsonfilho]

After remove ou shutdown the system, the screen freeze.

[faysalnadim]

@Leigh-M I apologies for not getting back on the previous comment. I don't know if this is still relevant to you but I was on Ubuntu 20.04 LTS/XPS 13 9380. I just enabled Wayland from the configs. Display Manager had become so resource hungry and it was causing issues for me. Just switched to Pop OS and so far the experience has been great.

[faysalnadim]

Were you able to fix it?

[delsonfilho]

I solved the problem activating X.Org X server and stop freezing the screen.

[basprins]

Is there actually a workaround /fix now?

[faysalnadim]

@basprins is your display showing low fresh while placing your laptop on dock? If yes, then one solution is to switch to Wayland.

[gfsd3v]

Same problem here

[nottux]

if you're on arch you want to install xf86-video-amdgpu-git if you've amd igpu to get the latest patch that fixes this issue

[jmandawg]

Thanks @tuxutku that fixed my issue as well.

[ipkpjersi]

I have this issue on a Ubuntu 22.04 laptop with a RTX 3060 and an AMD 6800H with the following xorg-server-core: xserver-xorg-core/jammy-updates,now 2:21.1.4-2ubuntu1.7~22.04.1 and NVIDIA 535.86.05 drivers.

I have worked around this issue with the following commands, preventing my laptop display from turning off when the lid is closed:

sudo sed -i '/IgnoreLid=/{s/false/true/}' /etc/UPower/UPower.conf 
sudo sed -i '/HandleLidSwitch/{s/#//;s/suspend/ignore/}' /etc/systemd/logind.conf