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

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](https://github.com/AdnanHodzic/displaylink-debian/files/13743858/60-displaylink.conf.TXT)
[/etc/lightdm/start_all_xrandr_fast.sh](https://github.com/AdnanHodzic/displaylink-debian/files/13743866/start_all_xrandr_fast.sh.TXT)

### 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). https://github.com/DisplayLink/evdi/issues/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)