DisplayLink Screens Not Outputting

[Keremimo]

Hello and thank you for your hard work.

I have a DisplayLink dock that powers two monitors, working fine in GNOME and Hyprland, but unable to output in Niri.

When I enter niri msg outputs, the displays are not showing.

This is the output I get when I do journalctl -eb /run/current-system/sw/bin/niri:

Dec 31 11:32:52 ThinkChad niri[10580]: 2024-12-31T10:32:52.824671Z  INFO niri: starting version 0.1.10-1 (unknown commit)
Dec 31 11:32:52 ThinkChad niri[10580]: 2024-12-31T10:32:52.828279Z DEBUG niri_config: loaded config from "/home/kerem/.config/niri/config.kdl"
Dec 31 11:32:53 ThinkChad niri[10580]: 2024-12-31T10:32:53.123778Z  INFO niri::backend::tty: using as the render node: "/dev/dri/renderD128"
Dec 31 11:32:53 ThinkChad niri[10580]: 2024-12-31T10:32:53.188319Z DEBUG niri::backend::tty: device added: 57857 "/dev/dri/card1"
Dec 31 11:32:53 ThinkChad niri[10580]: 2024-12-31T10:32:53.518640Z DEBUG niri::backend::tty: this is the primary node
Dec 31 11:32:53 ThinkChad niri[10580]: 2024-12-31T10:32:53.518657Z DEBUG niri::backend::tty: this is the primary render node
Dec 31 11:32:53 ThinkChad niri[10580]: 2024-12-31T10:32:53.541087Z DEBUG niri::backend::tty: device changed: 57857
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.556158Z DEBUG niri::backend::tty: new connector: eDP-1 "Thermotrex Corporation TL140BDXP01-0 Unknown"
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.556340Z DEBUG niri::backend::tty: new connector: DP-1 "PNP(AOC) 27G2WG3- 1TMP9HA011448"
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.556509Z DEBUG niri::backend::tty: connecting connector: DP-1
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.556654Z DEBUG niri::backend::tty: picking mode: Mode { name: "1920x1080", clock: 325670, size: (1920, 1080), hsync: (1944, 1976, 2056), vsync: (1083, 1088, 1100), hskew: 0, vscan: 0, vrefresh: 144, >
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.556828Z DEBUG niri::backend::tty: set max bpc to 8
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.568865Z DEBUG niri::niri: putting output DP-1 at x=0 y=-1080
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.568933Z DEBUG niri::backend::tty: connecting connector: eDP-1
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.569093Z DEBUG niri::backend::tty: picking mode: Mode { name: "2560x1440", clock: 496130, size: (2560, 1440), hsync: (2608, 2640, 2720), vsync: (1463, 1468, 1520), hskew: 0, vscan: 0, vrefresh: 120, >
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.569216Z DEBUG niri::backend::tty: set max bpc to 8
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.582735Z DEBUG niri::niri: putting output eDP-1 at x=0 y=0
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.582996Z DEBUG niri::backend::tty: device added: 57856 "/dev/dri/card0"
Dec 31 11:32:54 ThinkChad niri[10580]: MESA-LOADER: failed to retrieve device information
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.599271Z  WARN niri::backend::tty: error adding device: None of the following EGL extensions is supported by the underlying EGL implementation, at least one is required: ["EGL_EXT_device_drm"]
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.599289Z DEBUG niri::backend::tty: device added: 57858 "/dev/dri/card2"
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.606191Z  WARN niri::backend::tty: error adding device: None of the following EGL extensions is supported by the underlying EGL implementation, at least one is required: ["EGL_EXT_device_drm"]
Dec 31 11:32:54 ThinkChad niri[10580]: 2024-12-31T10:32:54.606224Z  INFO niri: listening on Wayland socket: wayland-1

I checked to see if there was an environment variable but my searching skills failed me.

Here's what shows when I list the current available cards:
ls /dev/dri/by-path/
pci-0000:00:02.0-card pci-0000:00:02.0-render platform-evdi.0-card platform-evdi.1-card

Thank you very much for reading.

System Information

• niri version: niri 0.1.10-1 (unknown commit)

• Distro: NixOS 24.11 Stable

• GPU: Intel HD 620

• CPU: Intel Core i5 8250

[YaLTeR]

Hm, not really sure. Do they work on cosmic-comp? If not, then could you open an issue in Smithay?

[Keremimo]

I'll check if it works on Cosmic tomorrow, will let you know. Thanks!

[cmeissl]

This will most likely require using a software renderer like the PixmanRenderer.

[valpackett]

This will most likely require using a software renderer like the PixmanRenderer.

Absolutely not, why would it? If you have a GPU, you can always render into an offscreen target for whatever purpose (including remote desktop sessions etc.) 🙃

With evdi that target itself is managed at the DRM level. So a DisplayLink setup is just kind of an inverted multi-GPU: instead of an extra render-only device you get an extra output-only device, and you need to use the primary GPU to render into the secondary's memory.

See mutter#615.

[cmeissl]

This will most likely require using a software renderer like the PixmanRenderer.

Absolutely not, why would it? If you have a GPU, you can always render into an offscreen target for whatever purpose (including remote desktop sessions etc.) 🙃

With evdi that target itself is managed at the DRM level. So a DisplayLink setup is just kind of an inverted multi-GPU: instead of an extra render-only device you get an extra output-only device, and you need to use the primary GPU to render into the secondary's memory.

Yeah, no, this is not how things work. You can not blindly assume that importing buffers from different subsystems or devices/drivers just works. The display link drm device will probably require linear dumb buffers for scanning out the framebuffer. Rendering into dumb buffers with something like GLES is not guaranteed to work, so you need to be prepared to render into an offscreen buffer compatible with the render node and transfer the memory to the (dumb) buffer compatible with the display link device.

An important optimization of wayland compositors is to avoid re-drawing/copying stuff that did not change. This is typically done with some kind of damage tracking base on buffer ages. You definitely do not want to copy the whole buffer from the render node to the display link node every time some small part changes.

smithay already provides an abstraction to deal with multi-gpu setups that tries to avoid copies between devices.
The multi-gpu renderer tries to find dma-buffer sharable between both nodes, falling back to cpu-copy (downloading pixels from the render gpu). It also makes sure to only transfer/copy damaged regions to target framebuffer.

Transferring those damage rects from the offscreen render buffer to the target framebuffer is what currently would require using something like the PixmanRenderer in smithay. This might still allow to use a shared dma buffer and use an slightly more optimized transfer when we can directly map the render dmabuf instead of having to ask something like GLES to download the pixels for us. But there is no guarantee that we find a suitable format for this. To give an example there are gpu drivers that might not allow to render into a linear buffer, in which case we can not access the buffer directly.

I did some tests in the past using dumb-buffers and pixman for drawing client dmabuf with pretty good results (though I do not have the numbers available). So sometimes it might even be more performant to explicitly not use the gpu for composition. Pretty sure that fullscreen clients and shm clients would fall into this.

See mutter#615.

Yes, this is an optimization we should also do, but as said can not rely on. There is even an linked issue with an still open MR to disable it for some setups where you have two GPUs from the same vendor which are unable to share memory.

The whole multi-gpu/split kms topic is a bit brittle imo.