You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...)
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.
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)
The text was updated successfully, but these errors were encountered:
Find below my workarounds for a couple of issues with my system and DisplayLink. With these applied, all works perfectly:
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:/opt/displaylink/udev.sh
script, called by the DisplayLink udev rule, will runsystemctl start displaylink-driver
udevadm settle
call insystemd-udev-settle
will wait for all currently running udev rules processing to finishdisplaylink-driver.service
is constrained asAfter=display-manager.service
display-manager.service
resolves tolightdm-service
, which (as it seems, could not find the exact chain of dependencies) is blocked from starting by the not-yet-finishedsystemd-udev-settle
systemd-udev-settle
, and the startup proceedsI assume this happens for all systems pulling in
systemd-udev-settle
(no discussion here on the merits ofudevadm 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 inudev.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/
by
For this issue, I would actually recommend applying the
--no-block
generally in theudev.sh
as part ofdisplaylink-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 intoudev.sh
after runningdisplaylink-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 bydisplaylink-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 (specificallyslick-greeter
; where one can type the password to log in) does not show in my setup on the DisplayLink screens. This may also be alightdm
orlightdm-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 withXorg
(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 ofDisplayLinkManager
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 setsddm
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)The text was updated successfully, but these errors were encountered: