Linux Mint 21 Vanessa w/ amdgpu: delay during startup; xorg.conf amdgpu fragment; lightdm login screen

[bsimmel]

Find below my workarounds for a couple of issues with my system and DisplayLink. With these applied, all works perfectly:

• delay during startup
• xorg.conf amdgpu fragment
• lightdm login screen

System:
  Host: Condor Kernel: 5.15.0-91-generic x86_64 bits: 64
    Desktop: Cinnamon 5.4.12 Distro: Linux Mint 21 Vanessa
Graphics:
  Device-1: AMD Cezanne driver: amdgpu v: kernel
  Display: x11 server: X.Org v: 1.21.1.4 driver: X:
    loaded: amdgpu,ati,modesetting unloaded: fbdev,vesa gpu: evdi resolution:
    1: 2560x1440~60Hz 2: 1600x1200~60Hz
  OpenGL: renderer: RENOIR (renoir LLVM 15.0.7 DRM 3.42 5.15.0-91-generic)
    v: 4.6 Mesa 23.0.4-0ubuntu1~22.04.1
--------------- Linux system info ----------------
Distro: Linuxmint
Release: vanessa
Kernel: 5.15.0-91-generic

---------------- DisplayLink info ----------------
Driver version: 1.14.1
DisplayLink service status: up and running
EVDI service version: 1.14.1

------------------ Graphics card -----------------
Vendor: amdgpu
Subsystem: Cezanne
VGA: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne (rev c9)
VGA (3D): 
X11 version: 21.1.4-2ubuntu1.7~22.04.5
X11 configs: /etc/X11/xorg.conf.d/20-displaylink.conf

-------------- DisplayLink xorg.conf -------------
File: /etc/X11/xorg.conf.d/20-displaylink.conf
Contents:
 #Section "Device"
#    Identifier "AMDGPU"
#    Driver     "amdgpu"
#    Option     "PageFlip" "false"
#EndSection

#Section "OutputClass"
#	Identifier "DisplayLink"
#	MatchDriver "evdi"
#	Driver "modesetting"
#	Option "AccelMethod" "none"
#	Option "PageFlip" "off"
#	Option "SWCursor" "on"
#	Option "ShadowFB" "true"
#EndSection

-------------------- Monitors --------------------
Providers: number : 5
Provider 0: id: 0x54 cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 2 associated providers: 4 name:Unknown AMD Radeon GPU @ pci:0000:09:00.0
Provider 1: id: 0xe6 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
Provider 2: id: 0xc5 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
Provider 3: id: 0xa4 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
Provider 4: id: 0x83 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

The DisplayLink device is DL-6950 dock with 2 monitors, sometimes also combined with classic HMDI/DP from the mainboard connectors.

The basic Linux Mint Cinnamon Desktop is mostly unchanged from defaults (afair; i.e. systemd booting into lightdm-greeter, then Xorg w/ Cinnamon).

delay during startup, from udev.sh script

During startup, there is a very long pause before lightdm-greeter login screen is shown. I found this to be due to Linux Mint running with openZFS by default, pulling in a dependency on systemd-udev-settle.service into the startup. When the DisplayLink device is connected during startup, this breaks in an interesting way:

• the /opt/displaylink/udev.sh script, called by the DisplayLink udev rule, will run systemctl start displaylink-driver
• the udevadm settle call in systemd-udev-settle will wait for all currently running udev rules processing to finish
• the starting of displaylink-driver.service is constrained as After=display-manager.service
• display-manager.service resolves to lightdm-service, which (as it seems, could not find the exact chain of dependencies) is blocked from starting by the not-yet-finished systemd-udev-settle
• -> finally after a long delay, systemd will terminate the long-running systemd-udev-settle, and the startup proceeds

I assume this happens for all systems pulling in systemd-udev-settle (no discussion here on the merits of udevadm settle...)

A workaround found also in other displaylink support scripts (https://aur.archlinux.org/packages/displaylink, https://github.com/displaylink-rpm/displaylink-rpm/, ...) is to pass --no-block to the service startup in udev.sh. It will then not delay the udev rules processing part of startup ("coldplug"), but work the same as without --no-block for dynamic hotplug.

Replace in /opt/displaylink/udev.sh/

systemctl start displaylink-driver

by

systemctl start displaylink-driver --no-block

For this issue, I would actually recommend applying the --no-block generally in the udev.sh as part of displaylink-debian.sh, since it is in use also by other parties (e.g. displaylink-rpm, archlinux). If you agree, I could provide a pull request, e.g. sed-ing it into udev.sh after running displaylink-installer.sh

xorg.conf fragment removal for amdgpu

With my system having an AMD "APU" (i.e. part of CPU module), the displaylink-debian.sh decides to put the respective xorg.conf fragment into /etc/X11/xorg.conf.d/20-displaylink.conf. With this, DisplayLink displays do not work at all, no "xrandr providers".

When removing the file, things are autodetected and work with no problems. I also (faintly, would need to recheck to confirm) remember it working with the default "OutputClass modesetting" fragment.

For this issue, I would argue that one can not easily make a general decision. I remember reading numerous recommendations to remove the file, also in the post-install-guide.md, yet given the number of possible HW variants + SW versions, it may well be the case that a sizeable number of users may need the setup as set by displaylink-debian.sh, but for others like me it breaks.

Since it is already mentionend in the post-install-guide.md, we may just leave it at that.

lightdm login screen not shown

I find that the lightdm-greeter login screen (specifically slick-greeter; where one can type the password to log in) does not show in my setup on the DisplayLink screens. This may also be a lightdm or lightdm-greeter issue, so other display-managers maybe do not show the problem.

I found the problem to be both that the "xrandr state" (for lack of a better term to describe it) is not consistent when the login screen is shown, so no other screens can be directly addressed by xrandr, and that when fixing this problem, the screens would still not activate automatically, but one has to activate them with an xrandr call.

I could work around both problems with a lightdm start script (attached), but I am not sure if the problem is A: general enough to be handled in displaylink-debian automatically, B: a good idea to manage all kinds of display manager start scripts in displaylink-debian.

/etc/lightdm/lightdm.conf.d/60-displaylink.conf
/etc/lightdm/start_all_xrandr_fast.sh

achieving consistent "xrandr state"

There seems to be a timing issue when DisplayLinkManager starts in tandem with Xorg (Xorg being started by lightdm), that results in the xrandr state not being initialized correctly, so that directly configuring display settings with "xrandr --output XXX" calls would not work.

The problem can be worked around by a sole xrandr call in a lightdm start script, or also by delaying the start of DisplayLinkManager
with respect to Xorg.

I also reported the problem to evdi. The interworking evdi-Xorg-kernel-DLM is complicated, but maybe they have more clue how to work on it (given the insight into DLM operation). DisplayLink/evdi#443

powering on the displays

With the "xrandr state" fixed, the login screen would still not show. But by now, calling xrandr --auto, again in the lightdm start script, powers up the DisplayLink displays.

It occurs to me that the issue here may actually be with lightdm or the lightdm-greeter (slick-greeter), which seemingly do not power up hotplugged displays. Connecting a monitor into a regular (not DisplayLink) connection would show the same behavior. It may not be a displaylink issue after all.

sddm NVIDIA fixes

While debugging all this, I found displaylink-debian.sh to set sddm display manager start scripts, when an NVIDIA setup is detected. I would assume that this only works for Debian systems using sddm as display manager, so e.g. not for Linux Mint, which I find uses lightdm instead by default. I can not test it without NVIDIA setup and not using sddm, but I would suggest that sddm use should be detected (I think, /etc/X11/default-display-manager would be the place on a Debian system), and a warning be printed when the system does not use it (I find providing start scripts for all kinds of display managers also asking too much from displaylink-debian, maybe the warning should display what needs to be done)