should start early and not powered down, for login screen

[bsimmel]

• Are you using the latest driver?
  yes, 5.8 package
• Are you using the latest EVDI version?
  yes, 5.8 package, 1.14.1 20230721
• If you are using a DisplayLink device, have you checked 'troubleshooting'
  on DisplayLink's website?
  yes
• Is this issue related to evdi/kernel?
  not yet clear, but I think it is rather kernel/evdi/Xorg than DLM, also displaylink.org forum is down

• Linux distribution and its version
• Linux kernel version
• Xorg version (if used)
• Desktop environment in use

$ inxi -G -S
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: amdgpu,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

I use a setup with DL-6950 dock, 2 monitors on it, with my workstation (i.e. as described above) and laptops (mine, wifes, work).

With the workstation, I usually do not have another monitor directly attached to it (so switching computers is really only plugging one cable).

When the workstation boots with the default driver setup (I use https://github.com/AdnanHodzic/displaylink-debian for installation, then only setting "--no-block" in the udev rule for service startup, and dropping the xorg.conf fragment, from inspection this matches closely the vanilla installer), the screens will not activate. I can type the password blindly and then lightdm display manager will transfer from the login screen (the lightdm greeter, namely "slick-greeter") to a full "cinnamon" desktop session. When the desktop session starts, the screens will activate.

So THE ISSUE IS:

I do not see the login screen, can not really tell if it is ready to type in the password, or if e.g. some boot problem happened. I would rather have the DisplayLinkManager(DLM)+evdi displays active already for the login screen.

I already drilled deeper with increased evdi and DRM logging, and (after some struggle...) found that a combination of running "xrandr" once, then again xrandr, but this time to activate the outputs, could activate the displays already such that the lightdm greeter would show on the screens. For this to work, the magic has to happen before running lightdm greeter, made possible by configuring a script that lightdm will run, with Xorg already started (in parallel), but before the lightdm greeter is run.

I would have also tried reporting this in displaylink.org forums, but the site is offline since at least days...

I think there are two aspects to the issue:

1.

The startup of DLM in parallel with Xorg seems a bit racy. I tried delaying the DLM startup some seconds in the systemd service file, so that Xorg would already be a bit more "settled". When doing so, running a single "xrandr" is not needed, so the combination of states seems to be consistent enough that one can directly configure/activate display settings with "xrandr --output ...". On the other hand, when not sequencing the startup as described in the systemd service file, a single "xrandr" call seems to also settle the state. Foe now, I go with the "xrandr" call.

The sequence here seems to be that Xorg opens the /dev/dri/cardX devices, then starts some DRM/KMS syscalls on them, and only at that point will DLM move in to set the "Connector state: connected". But Xorg seemingly/maybe? is not yet ready to act on the state change of the devices it just opened, and somehow the result is that "xrandr --output ..." would not work to configure/activate display settings. Delaying the DLM seems to help, as does forcing the consolidation of state with the "xrandr" call.

I have have no idea who is at fault here, could be any of kernel (KMS/DRM), Xorg (calling KMS/DRM frontend), evdi (implementing KMS/DRM backend + libevdi kernel side), DLM (libevdi interface)?

2.

OK, so when the Xorg state is consistent enough, as achieved in the previous step, the displays still do not seem to auto-activate, where they would auto-activate for (simple, plain and boring) directly GPU-driven connectors.

Running "xrandr --output DVI-I-1-1 --auto" achieves activating e.g. the 1st DisplayLink connector. Running "xrandr --auto" achieves activating any connected, but powered-down connectors. Only then would the lightdm greeter login screen be shown, yay!

Again I have no clear picture where I could turn the knobs to make the DisplayLink display pipes not start powered down. It occurs to me that the DisplayLink displays should activate just like regular displays, also like it works in windows, to support my described workflow. I think it is eigther Xorg deciding for whatever reason to not activate them, or the behaviour is given by evdi?

attached

• /etc/lightdm/start_all_xrandr_fast.sh to activate the DisplayLink screen for lightdm greeter
  start_all_xrandr_fast.sh.TXT

• /etc/lightdm/lightdm.conf.d/60-displaylink.conf to configure lightdm to use the script
  60-displaylink.conf.TXT

Except for these problems, DLM + evdi work nicely for me, thanks for the good work.