display (whole computer?) hangs when I attempt to use DisplayLink with Wayland

This will hopefully be fixed by https://gitlab.gnome.org/GNOME/mutter/merge_requests/953 .

Yes, using the vendor driver package is required, because it contains DisplayLinkManager program (proprietary and closed source) for driving the DisplayLink USB 3 devices.

This bug was fixed in the package mutter - 3.34.2-2ubuntu1

---------------
mutter (3.34.2-2ubuntu1) focal; urgency=medium

  * Merge with debian. Remaining changes:
    + debian/control:
      - Update VCS flags to point to launchpad
    + debian/gbp.conf: update branch to point to ubuntu/master
    + debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      - X11: Add support for fractional scaling using Randr

mutter (3.34.2-2) unstable; urgency=medium

  * d/p/EGL-Include-EGL-eglmesaext.h.patch: Cherry pick from master. This
    fixes the generated EGL includes for the move of exlext.h from mesa to
    libglvnd, which has just happened in Debian.

mutter (3.34.2-1ubuntu1) focal; urgency=medium

  * Merge with debian including new upstream version 3.34.2 (LP: #1857037):
    - Fix an hang when using DisplayLink with Wayland (LP: #1853357)
    - Kill window effects on destroy (LP: #1844222)
    - Fixed a crash when using various Java apps such as Intellij (LP: #1845281)
    - Fixed a crash when handling X11 events (LP: #1846403)
    - Fixed some double-scaling in wayland
    - More crash and hang fixes
    Remaining changes:
    + debian/control:
      - Update VCS flags to point to launchpad
    + debian/gbp.conf: update branch to point to ubuntu/master
    + debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      - X11: Add support for fractional scaling using Randr

mutter (3.34.2-1) unstable; urgency=medium

  * Team upload
  * New upstream release
    - d/libmutter-5-0.symbols: Update
    - d/copyright: Update
  * d/gbp.conf: Use upstream/3.34.x branch
  * Remove obsolete Lintian override
  * Standards-Version: 4.4.1 (no changes required)
  * d/tests: Use correct compiler for proposed autopkgtest
    cross-architecture testing support

 -- Iain Lane <email address hidden> Sun, 22 Dec 2019 17:24:36 +0000

Is this going to be fixed in Eoan?

Hello Jonathan, or anyone else affected,

Accepted mutter into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/mutter/3.34.3-1ubuntu1~19.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Given no reproducers are here and that this fix is coming from upstream, as per the GNOME SRU exception, I mark this as verified.

Sorry, I'm usually remote from the office where I have the displaylink adapter which has this problem, so I was not able to test until I got to the office instead.

I installed all updates in eoan-proposed and rebooted and then tried logging into a Wayland session and using the displaylink adapter, and the behavior hasn't changed: my display and perhaps my whole computer hangs within a minute or two of starting to use the displaylink adapter. Changing the display configuration consistently triggers the hang. This isn't fixed.

It sounds like the Fix Released status for focal is wrong.

Jonathan, can you please boot from USB and test 20.04?
http://cdimage.ubuntu.com/daily-live/current/

With Ubuntu 19.10:

I am not able to reproduce the issue with a single monitor of a
different brand plugged into the DisplayLink adapter. There are three
differences here and I don't have the equipment available where I am
right now to narrow down which of them is relevant:

* one monitor instead of two;
* different brand and dimensions of monitor; and
* I'm only using the HDMI plug on the DisplayLink adapter, not the DVI
  plug.

However, one thing I do observe with this configuration -- which
again, doesn't crash -- is that screen updates to the DisplayLink
monitor are Extremely Slow. Like I am typing in a terminal window and
it sometimes takes a second or two between when I type something and
when the results of the typing show up in the terminal. If I move the
same terminal window onto the built-in laptop display the lag goes
away.

The update lag does not occur when I use Xorg instead of Wayland.

Attempting to test Ubuntu 20.04 on same laptop booting from Thumb
drive:

Live CD user doesn't support Wayland.

Tried creating new user, Wayland wasn't available for that user
either.

Of course DisplayLink stuff isn't installed either, so the laptop
doesn't actually notice the DisplayLink display when I plug it in.

So to make this test work I would have to figure out how to install
Wayland in the running live image and install the DisplayLink stuff
too. The DisplayLink stuff I can figure out, but not sure about how to
enable Wayland sessions in the live image.

Attempting to test Ubuntu 20.04 on a slightly different laptop:

I upgraded a spare laptop to Ubuntu 20.04, managed to get DisplayLink
installed onto it (I had to tweak the installer package not to compile
and install the dkms modules and to use the ones that ship with Ubuntu
instead), and tested it. Again, keep in mind that in my current setup
I'm unable to reproduce the hanging issue, but I did reproduce the
display lag.

Next steps:

1. On the laptop where I encountered the hanging issue, I am using the
   evdi kernel module and library that are shipped with the
   DisplayLink reference implementation release from last July, rather
   than the newer module and library that are included in Ubuntu. I
   need to reinstall evdi on that laptop using the tweak I mentioned
   above for 20.04, so that I am using the Ubuntu version of the
   module and library with 19.10, to see if the problem persists.
   I.e., the crashing issue may resolve if I use the evdi kernel
   module and library that ship with Ubuntu.

2. If not, then test various configurations and try to identify which
   of the factors above triggers the issue (one monitor vs. two; brand
   and dimensions of monitor; HDMI vs. DVI plug in adapter).

3. Test whether I am able to reproduce the issue in 20.04 on the spare
   laptop with the monitor configuration with which I encountered the
   issue in 19.10.

4. Try to figure out how to install and enable both Wayland and the
   DisplayLink manager in a running Live CD session so that I can test
   with the laptop that I know has encountered this issue in the past.

Learning more about this as I go:

* I'm no longer convinced that I was correct above when I claimed that the version of the evdi kernel module and library shipped with Ubuntu are newer than the version shipped with the installer available on displaylink.com. I might be wrong about that.

* When I use the versions shipped with Ubuntu instead of the displaylink.com installer, on Ubuntu 19.04, then I can only use DisplayLink monitors under Wayland, i.e., they aren't detected under Xorg.

Sorry, I meant 19.10 in my last comment, not 19.04.

When I use the evdi module and library shipped with Ubuntu in 20.04, then DisplayLink works in Xorg, but it's very glitchy, with cursor artifacts showing up constantly all over the place on all screens, both DisplayLink and non-DisplayLink.

OK, so additional data...

19.10 also doesn't hang when I use the kernel module and library that ship with Ubuntu, so apparently the problem which prompted me to report this bug is limited to when using the kernel module and library that are installed by the installer on DisplayLink.com.

I'm not sure how to proceed with that knowledge, though, because the installer on DisplayLink.com doesn't offer an option of _not_ installing its own kernel module and library, and indeed, I believe it complains if the Ubuntu ones are installed and demands that you uninstall them. So while I was able to hack the installer to avoid that, I'm not sure there's a good end-user solution.

The issue remains that the responsiveness of the DisplayLink displays is exceedingly poor.

This is a maze of twisty little passages and I'm not really sure how to proceed. There are clearly things that need to be improved but I'm not sure how to classify or report them, which makes me tempted to just throw up my hands and give up, which would not be the best outcome. :-/

Some guidance?

Hi Jonathan,

you seem to be having several different issues here, so I'll try to address them individually.

First the slow updates, you wrote: "screen updates to the DisplayLink monitor are Extremely Slow. Like I am typing in a terminal window and it sometimes takes a second or two between when I type something and when the results of the typing show up in the terminal. If I move the same terminal window onto the built-in laptop display the lag goes away."

Slow updates could be one of two things: either the copying of content to DisplayLink itself is slow, or DisplayLink is showing outdated content. To understand which one it is, you could try running 'glxgears' (or any program that animates continuously and reports fps) on the DisplayLink output and then see if the same slowness with a terminal still happens.

If the issue is outdated content, then 'glxgears' by forcing repeated output updates should have the side-effect of making the slowness go away. Also glxgears should report the expected monitor refresh rate as fps (for a 60 Hz monitor I'd expect 58 - 60 fps). Your overall system CPU consumption could be somewhat high, but I would not expect any CPU core to be maxed out.

If the issue is bad performance in copying the content, then running glxgears should not make the slowness disappear. Instead, glxgears should report very low fps, and your system CPU usage may or may not be high. It would be interesting to know if you have any CPU cores maxed out busy.

In any case, I think we should talk about the slowness in a new bug report. Please, point me to it, if you file one.

Xorg cursor artifacts all over everywhere: "When I use the evdi module and library shipped with Ubuntu in 20.04, then DisplayLink works in Xorg, but it's very glitchy, with cursor artifacts showing up constantly all over the place on all screens, both DisplayLink and non-DisplayLink."

I've seen it, it is a know issue and has a workaround: setting "PageFlip" "false" in xorg.conf. This link is not exactly about cursor issues but explains how to set the PageFlip workaround:
https://support.displaylink.com/knowledgebase/articles/1181623-displaylink-ubuntu-driver-after-recent-x-upgrades

Anyway, that is off-topic too for this issue, so if you want to discuss that, I again suggest a new report. I don't think I can help with that though.

What comes to the EVDI dkms version, the official DisplayLink driver 5.2.14 package contains EVDI 1.6.2. The release notes just write it out as v1.5.0-r1-76 (a1e1135), but that sha1 refers to 1.6.2 and the code between the official package and the 1.6.2 tag for the kernel module is identical. So I think the ones shipped in Ubuntu/Debian are older than the DisplayLink's own.

I see that the Ubuntu evdi 1.6.0+dfsg-1ubuntu2 (the version I see in Ubuntu 19.10) contains some patches on top of 1.6.0, but none of those are GNOME Wayland related fixes found in 1.6.2. OTOH, it seems 1.6.2 already contains all the patches that Ubuntu adds.

This probably makes no difference to your issues, but I'd prefer to stick to the DisplayLink official version to avoid confusion on what is actually being tested.

1.6.3 and 1.6.4 exist too, they have one patch each to libevdi0. I cannot off-hand say if those might be relevant or not.

Then the main issue: freezes.

Do I understand correctly, that so far the freezes have only happened when you have had two monitors attached to the DisplayLink dock? Never with just one monitor?

Which DisplayLink dock do you have?

You said changing the display configuration is a sure way to freeze? What do you do exactly, something in GNOME display settings or plugging cables or?

I doubt the HDMI vs. DVI or monitor brand/model would have an effect here, so I think you can leave testing those details for later.

For now, I would like us to concentrate on Ubuntu 19.10, and the full DisplayLink driver package 5.2.14 which includes the EVDI kernel module and libevdi0.

Verify what version of libmutter-5-0 package you have installed exactly. If it's older than the one mentioned here to contain the fix I thought would help, try to get that updated. Let me know what version you have, I can have a go at reproducing the freeze.

When your machine freezes, can you access it from a remote, e.g. via ssh?

If you can, you could first take a look at the process list: are gnome-shell and DisplayLinkManager running? Do they consume CPU?

The next step would be installing a bunch of dbgsym packages and attaching GDB to gnome-shell when it's frozen to see where it is at. Do you know how to do that?

Re: DisplayLink monitors not detected under Xorg, I wonder if that would have to do with https://gitlab.freedesktop.org/xorg/xserver/issues/909 ?

But that's off-topic in this report too.

You say that the library and kernel module in Ubuntu are older than the ones from DisplayLink.com. Can you explain why the current versions of the module and library aren't being shipped in Focal?

I'm afraid I can't test any further in 19.10 since I've already upgraded both of my laptops to 20.04. :-(

And I can't test the kernel module and library from the DisplayLink.com release in 20.04 because (as noted above) they don't build successfully.

I've been in contact with the DisplayLink.com folks and they say that they are working on an updated release for 20.04. So perhaps at this point all that I can do is wait for that to come out and then retest eveything and we can figure out what to do from there if there are still issues.

Unfortunately I have no idea why something is or is not shipped in Focal.

Sorry, I did not understand from the above that you cannot build the driver package's EVDI module or library on 20.04. Can you point me to the displaylink.com discussions if those happen to be public? I'm curious.

I can still give it a try on Ubuntu 19.10 to see if I can trigger any kind of freeze with two monitors plugged in via DisplayLink.

According to https://packages.ubuntu.com/source/focal/mutter Focal today has libmutter based on 3.34.3 upstream release which already contains backported patches from https://gitlab.gnome.org/GNOME/mutter/merge_requests/953 , so this would be something else. I assume that will be upgraded to 3.36 in 20.04 still.

It was a private email exchange between me and the DisplayLink folks. Basically, I emailed them and told them them their package wasn't working on 20.04 and asked them to fix it and they emailed back and said they're working on it.

I tested with a Dell D3100 dock and two monitors connected to the dock via HDMI in addition to laptop built-in screen. I did this on Ubuntu 19.10 with the libmutter fix from eoan-proposed (libmutter-5-0 package version 3.34.3-1ubuntu1~19.10.1).

I tried unplugging and hotplugging each HDMI cable individually and together. I tried hotplugging and unplugging the dock itself (USB). I tried booting with the dock connected, and booting with the dock disconnected then hotplugged.

With all three monitors on, I left one glxgears running on one DisplayLink output and the laptop screen each, and a terminal printing the fps on the other DL output for 10 minutes. Then I changed the refresh rate of one DL output to 50 Hz and the other DL output to 75 Hz, confirmed from the monitors themselves to actually run with those refresh rates, and left things running for a couple of minutes more. (Everything defaulted to 60 Hz before.)

I was unable to reproduce any kind of freeze.

However, I did notice that with three monitors, gnome-control-center Display settings is crash-happy if any monitor was disabled. But that is off-topic here, because even that did not cause anything to freeze.

I did also observe the "outdated content" issue I referred to in my earlier comment here. That should be fixed in EVDI kernel module once DisplayLink releases an update.

This specific bug was fixed upstream, feel free to open another for similar scenarios please.

So what's the situation of this bug in eoan then? I assume it's still verification-failed? Will there be a follow up fix upload for mutter there?

As per my discussion with Laney, I will be releasing the mutter + gnome-shell SRU that's currently in eoan-proposed, even though it doesn't seem to be fixing all the issues for users. We'll be re-opening the bugs so that they can be investigated further.

This bug was fixed in the package mutter - 3.34.3-1ubuntu1~19.10.1

---------------
mutter (3.34.3-1ubuntu1~19.10.1) eoan; urgency=medium

  * Backport to eoan (LP: #1858683)

mutter (3.34.3-1ubuntu1) focal; urgency=medium

  * Merge with debian. Remaining changes:
    + debian/control:
      - Update VCS flags to point to launchpad
    + debian/gbp.conf: update branch to point to ubuntu/master
    + debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      - X11: Add support for fractional scaling using Randr

mutter (3.34.3-1) unstable; urgency=medium

  * New upstream release
    + Fix window recording on HiDPI
    + Fix top-left pixel being insensitive to clicks (LP: #1849135)

mutter (3.34.2-2ubuntu1) focal; urgency=medium

  * Merge with debian. Remaining changes:
    + debian/control:
      - Update VCS flags to point to launchpad
    + debian/gbp.conf: update branch to point to ubuntu/master
    + debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      - X11: Add support for fractional scaling using Randr

mutter (3.34.2-2) unstable; urgency=medium

  * d/p/EGL-Include-EGL-eglmesaext.h.patch: Cherry pick from master. This
    fixes the generated EGL includes for the move of exlext.h from mesa to
    libglvnd, which has just happened in Debian.

mutter (3.34.2-1ubuntu1) focal; urgency=medium

  * Merge with debian including new upstream version 3.34.2 (LP: #1857037):
    - Fix an hang when using DisplayLink with Wayland (LP: #1853357)
    - Kill window effects on destroy (LP: #1844222)
    - Fixed a crash when using various Java apps such as Intellij (LP: #1845281)
    - Fixed a crash when handling X11 events (LP: #1846403)
    - Fixed some double-scaling in wayland
    - More crash and hang fixes
    Remaining changes:
    + debian/control:
      - Update VCS flags to point to launchpad
    + debian/gbp.conf: update branch to point to ubuntu/master
    + debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      - X11: Add support for fractional scaling using Randr

mutter (3.34.2-1) unstable; urgency=medium

  * Team upload
  * New upstream release
    - d/libmutter-5-0.symbols: Update
    - d/copyright: Update
  * d/gbp.conf: Use upstream/3.34.x branch
  * Remove obsolete Lintian override
  * Standards-Version: 4.4.1 (no changes required)
  * d/tests: Use correct compiler for proposed autopkgtest
    cross-architecture testing support

 -- Marco Trevisan (Treviño) <email address hidden> Wed, 08 Jan 2020 13:31:04 +0000

The verification of the Stable Release Update for mutter has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

On Eoan, I was able to trigger a freeze when trying to set the DisplayLink output as the only output. I have proposed a fix for that in https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209 , maybe it could help here as well?

The Eoan Ermine has reached end of life, so this bug will not be fixed for that release