Getting DisplayLink to work on a fresh installed Debian testing took more time than expected. One reason for this was for sure my lack of knowledge about the output providers infrastructure in xrandr. I was coming from an Ubuntu 14.04 system, where DisplayLink was working more or less stable. After upgrade to Ubuntu 16.04 it still was working, but the internal sound card of my system wasn’t - and sometimes the soundcard of my docking station only was working after a replug. That was the situation, where I thought: A reinstall of the system would be great - and I simply choose Debian, it usually works.

Installing Debian

Installing Debian was quite simple - the only challenge was booting in UEFI. It seems, that Dell XP13 9350 can’t boot from an external USB DVD drive in UEFI mode… however, writing the Debian Testing DVD onto an USB pen drive and booting from the USB pen drive works. I even managed to keep the content of my main drive to avoid copying my files. Therefore I moved all folders into a new folder “/ubuntu”, so that I have it still available, if I need it. I did this from a shell of the Debian installer, before I started the install.

After the install was complete, Debian booted. One downside is, that I didn’t have network connection during the install. For the Intel wireless card, the firmware from non-free repository would have been required. And the USB ethernet card from the dock wasn’t recognized by the installer system. However, it worked after booting into the fresh installed Debian system. This allowed me to download the DisplayLink driver.

Although the driver is for Ubuntu, it should work on Debian, too. I was surprised by the install script claiming that the kernel header were missing. Strange. I verified: build-essential, linux-headers-amd64 are installed. I also needed dkms in order to build the evdi kernel module. But still - appearantly the kernel headers are missing. But: ls -l /lib/modules/4.6.0-1-amd64/ shows that the build/ symlink is present and the contents of it ls -l /lib/modules/4.6.0-1-amd64/build/ is not empty. The kernel headers seems to be present.

It’s time to dissect the displaylink download. The downloaded archive “DisplayLink USB Graphics Software for Ubuntu 1.2.zip” contains the binary “displaylink-driver-1.2.58.run”. This in turn is itself an archive which contains the install script that checks for the kernel headers. With ./displaylink-driver-1.2.58.run --help you can find out that with ./displaylink-driver-1.2.58.run --keep --noexec --target displaylink-driver-1.2.58 the install scripts will be extracted to the subdirectory displaylink-driver-1.2.58/ without executing the script. Now you can modify the install script displaylink-driver-1.2.58/displaylink-installer.sh. In the function “check_requirements()” you see, that the script checks for the existence of the file /lib/modules/4.6.0-1-amd64/build/Kconfig. If it doesn’t exist, it spits out “Unsatisfied dependencies. Missing component: Linux headers for running kernel, 4.6.0-1-amd64”. I simply commented out this line as I know, I have the kernel headers installed. Now I can run the install script manually with ./displaylink-installer.sh install.

After a reboot, the external monitor still doesn’t show anything. xrandr only lists the internal monitor. The monitor configuration of Gnome3 is the same. While researching the problem, I found the DisplayLink installer for Debian with an interesting Post Installation Guide.

I could verify that the service is running (ps -ef|grep DisplayLink and systemctl status dlm.service). The next section about “Providers” is interesting: xrandr --listproviders gave me this output - indicating the DisplayLink is working:

Providers: number : 2
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 1 name:modesetting
Provider 1: id: 0x14e cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

Provider 1 is the DisplayLink output. After enabling this output via xrandr --setprovideroutputsource 1 0 the external monitor is detected. I can enable it and it shows my desktop.

Troubleshoot slow screen updates

However - it is very, very slow. It updates the screen faster, if I move the mouse. But the lag is too annoying. More researching… ArchLinux has an wiki entry about DisplayLink with a troubleshooting section. But changing the modeline didn’t give the desired result: The screen was frozen then. Also disabling the background image didn’t help.

I was a bit concerned about seeing the name “modesetting”. I suspected, that I’m not using the Intel graphics driver. However, using the internal monitor, the graphics acceleration seems to work, as Gnome3 makes use of it. Using glxinfo (apt-get install mesa-utils) showed, that I indeed use the correct acceleration. While researching, I stumbled across the following news: Debian now defaults to modesetting driver. This also contains the workaround to use the Intel driver: cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11. After a reboot, the xrandr providers show like this:

Providers: number : 2
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 1 name:Intel
Provider 1: id: 0x14e cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

Now the first provider uses “Intel”. And DisplayLink output works.

The issue is probably in the way, of the two graphics cards are synchronized - keyword PRIME Synchronization. The were some bugs in the intel driver, e.g. 96380 - Reverse PRIME - which are fixed and that’s why my configuration works with the Intel driver. The changelog for the modesetting driver shows, that it is still in active development. And especially the change modesetting: Fall back to primary crtc for vblank looks promising to solve the issue, I’m seeing:

This fixes glxgears running at 1 fps when fully covering a slave-output and the modesetting driver is used for the master gpu.

The commit is on the master branch, so it will be included in the upcoming 1.19 release of Xorg/xserver.

Helper scripts for xrandr

In order to switch between the monitors quite simple, I’ve created a shell script, that I place under ~/bin/xrandr-set:

#!/bin/bash

xrandr --setprovideroutputsource 1 0

ext=$(xrandr --current|grep DVI|cut -d " " -f 1)
int=$(xrandr --current|grep eDP|cut -d " " -f 1)

extMode="1920x1200"
intMode="3200x1800"

if [ "$1" = "dual" ]; then
    xrandr --output $ext --mode $extMode --primary --right-of $int --output $int --mode $intMode
elif [ "$1" = "ext" ]; then
    xrandr --output $ext --mode $extMode --primary --output $int --off
else
    xrandr --output $ext --off --output $int --mode $intMode --primary
fi

Now I can switch to the internal monitor only by executing xrandr-set. Switching on the external only, is xrandr-set ext. Both monitors is xrandr-set dual.

Update 2016-10-01: Syslog messages

With this setting, the syslog is flooded with messages, e.g.

Oct  1 13:12:05 debian kernel: [161127.898744] [drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x400015a, supported mask 0x7400003f
Oct  1 13:12:05 debian kernel: [161128.319611] [drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x15b, supported mask 0x7400003f

The messages are also described in a DisplayLink Forum thread.

Hopefully, this is also solved with a new xserver and the modesetting driver.