How KDE Plasma handles Displaylink on Wayland?

I’m struggling to get Hyprland package to work with displaylink. It seems to keep failing while KDE Plasma manages to work with it just fine. Does anyone know where to find information what “tricks” KDE Plasma plays to handle Displaylink devices (on Wayland)?

I am not using DisplayLink device currently, because I use desktop, but I used it previously.
One of the way to understand how it works is to look in the code.

1 Like

It’s handled by KWin, with a CPU fallback for multi gpu copies. Afaik wlroots is missing that

1 Like

Thanks, could you please help me find the relevant part of the code? I’ve cloned kwin and grepped for “displaylink” and “evdi” (and a few combinations), but nothing came out.

Wlroots compositor (hyprland) seems to fail at the wlr_backend_get_drm_fd step, so I’m looking for a similar bit of code in kwin (the bit that opens an evdi drm device and initializes an “egl context”).

Thanks, does it mean that Kwin uses llvmpipe or another software-based rendering method to display it’s screen or does it render it on the GPU (integrated one) if it’s available?

CPU fallback for multi gpu copies

Sorry, I’m not quite sure what it means? What are the “mutli gpu copies”?

Wlroots seems to ask for WLR_RENDERER_ALLOW_SOFTWARE variable to be added, so I’m not sure if it’s necessary, if it’s mistake on my part or if it’s just not implemented in wlroots yet.

CPU fallback means that KWin does its compositing and then reads the result from the GPU into system memory, and points DisplayLink to the image in system memory.

1 Like

@Zamundaaa Thank you, so CPU is “relaying” pixelbuffer/GEM objects/DMA-bufs (sorry, not quite sure how this all works yet) and displaylink just does “modesetting”? Do you know if there were any discussions/issues on the mailing list or on the gitlab/forums where I could read more about it? I’m trying to debug it right now and it’s really hard without seeing “the bigger picture”.

Hyprland errors saying that it should turn on software rendering (WLR_RENDERER_ALLOW_SOFTWARE) , but from what you said Intel GPU should already provide rendering for wlroots and Hyprland Compositor should connect the two together?

Yes. DisplayLink is just a display device, there’s no GPU. For it to show stuff, the compositor has to copy data over to a buffer allocated for the DisplayLink device.

1 Like

Thanks, that makes sense now. Sadly, I still can’t figure out what causes Hyprland to reject Displaylink’s device node and after 3 days of tough debugging I may need to come to conclusion that this may just be cosmos’ way to say “move on”…

I will try Miracast for now. Maybe the visual quality won’t be much worse from DisplayLink. And it seems that it’s possible to use gnome’s implementation without installing their entire DE.

I quickly gave up on Miracast after seeing a few demos with very high latency and kept on reading and trying to understand how multiGPU and devices without a render node (DisplayLink) are meant to work in a Wayland Compositor. There were many merge requests needed to get this to work in wlroots - they looked really complex, but the developers (Aleksander Orzechowski and Simon Ser) worked on them actively.

There is a workaround in the linked Gitlab issue, however it effectively disables multiGPU support, which is the very reason why I’m trying to switch to a wlroots compositor from KDE in the first place (and of course the rounded window corners).

For now I had to get a laptop stand and use the built-in monitor like a pleb, but I’ll switch to Hyprland and daily drive it until proper support gets merged into wlroots. Fingers crossed…