[Solved] Sway Multihead problem - i915, DisplayLink, Mesa > 25.1.2-1

jabbo · 2025-09-17 17:18:32

I have a bit of a weird problem and I've run out of ideas where to look. I do hope I didn't overlook something obvious.

Basic system info

- I'm using Sway (1.11) on my laptop (Lenovo T490)
- My graphics card identifies as "Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620] [8086:3ea0] (rev 02)"
- The driver in use is i915
- I have a lenovo docking station which lsusb identifies as "DisplayLink ThinkPad Hybrid USB-C with USB-A Dock"

For some reason, this isn't officially supported by Sway, so I run it with the `--unsupported-gpu` parameter.

Problem: Sway crashes on start in multihead environment

If I just use the laptop, everything runs fine.

However, if I use my docking station, which has two external monitors and is connected via USB-C. There, I run into problems.

When I run `sway --unsupported-gpu`, it crashes immediately, giving the following error.

00:00:01.790 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list."
00:00:01.798 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list."
00:00:01.841 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list."
00:00:01.841 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list."
00:00:01.841 [ERROR] [wlr] [render/egl.c:490] Failed to get DRM device: No such device
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
00:00:01.865 [ERROR] [sway/server.c:171] !!! Proprietary DisplayLink drivers are in use !!!
00:00:01.865 [ERROR] [sway/server.c:171] !!! Proprietary DisplayLink drivers are in use !!!
00:00:01.865 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list."
00:00:01.865 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list."
Fontconfig warning: using without calling FcInit()
2025-09-17 16:18:50 - [swaybg-1.2.1/main.c:571] wl_display_roundtrip failed

Workaround: downgrade mesa to version 25.1.2-1

After searching for some of the errors above, one result (which I sadly can't find anymore) suggested downgrading mesa. And in fact, that works.

The downside of this is that I'm running my system with outdated drivers now. Some applications (e.g. cinny) start complaining about that. Nothing that I can't live without for now, but that might change.

I also tried the current `mesa-amber`, but that crashes with almost identical error messages, only that it also fails to load evdi:

MESA-LOADER: failed to open evdi: /usr/lib/dri/evdi_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: evdi

Question

Can you help me understand what is the actual problem, here? I don't even know where to start.

- Is it a DisplayLink issue, because it works fine without the docking station?
- Is it a Mesa issue, because the workaround works?
- Is there something I can configure or do to make it work with the current drivers?

Any help would be greatly appreciated. Thanks in advance.

Last edited by jabbo (2025-10-12 15:37:48)

V1del · 2025-09-17 20:37:05

https://docs.mesa3d.org/relnotes/25.2.3.html#bug-fixes mentions a regression with dGPUs that got fixed, which somewhat reads like your problem, so try an fresh update first.

jabbo · 2025-09-17 21:50:15

Thanks, will try once 25.2.3 hits the repos.

Just out of curiosity: You mean this bit: "Regression since mesa 25.2.0: applications waiting for dGPU to start", right?

jabbo · 2025-09-18 06:42:44

Sadly, the issue doesn't go away with Mesa 25.3. Same issue, same errors.
But thanks for the idea, V1del. I haven't had much hope, though, since the release note you mentioned talks about dGPUs and I have an integrated one.

seth · 2025-09-18 08:32:53

When was the last time you updated https://github.com/archlinux/aur/tree/evdi-dkms ?

jabbo · 2025-09-18 09:17:30

Thanks for the suggestion. "evdi-dkms" was up to date (v 1.14.11-1). Just tried "evdi-dkms-git", too.
It makes no difference. Identical error messages.

Last edited by jabbo (2025-09-18 09:28:23)

seth · 2025-09-18 11:56:45

Does "eglinfo" work w/ the dock/evdi attached?
Check

ls /dev/dri/card*

and if there're multiple cards, try to select one or more of them resp. manipulate the order

WLR_DRM_DEVICES=/dev/dri/card0 sway
WLR_DRM_DEVICES=/dev/dri/card1 sway
WLR_DRM_DEVICES=/dev/dri/card0:/dev/dri/card1 sway
WLR_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0 sway

jabbo · 2025-09-18 17:03:42

Thanks seth, that yielded a few interesting results:

eglinfo

seth wrote:

Does "eglinfo" work w/ the dock/evdi attached?

Depending on what you mean by "work", I guess. It runs, and produces roughly 1900 lines of output and exits. Anything specific I should look for?
One thing caught my eye:

Wayland platform:
eglinfo: eglInitialize failed

Buuut: if I run eglinfo after downgrading mesa again (with everything working), it reports the same failure for the Wayland platform.

That made me look into differences of eglinfo's output.
In the working setup with the downgrade, it reports:

MESA-LOADER: failed to open dri: libLLVM.so.19.1: cannot open shared object file: No such file or directory (search paths /usr/lib/gbm, suffix _gbm)

It also reports four platforms as failed: GBM, Wayland, X11 and Surfaceless, e.g.

GBM platform:
eglinfo: eglInitialize failed

While in the broken setup with the current mesa drivers, there is nothing about a MESA-LOADER, and it reports only the platforms Wayland and X11 as failed. GBM and Surfaceless seem fine.

So paradoxically, the setup that works complains about a lot of failures. I have no clue what to make of that. Any ideas?

Select devices

seth wrote:

Check
ls /dev/dri/card*
and if there're multiple cards, try to select one or more of them resp. manipulate the order

I did that. It reports three devices:

/dev/dri/card0 /dev/dri/card1 /dev/dri/card2

I tried different combinations, as you suggested:
If I call sway with

card0, my HP monitor turns on and shows sway, but with a lot of rendering errors.
card1, my laptop display shows sway, seems OK
card2, my LG monitor turns on and shows sway, but with a lot of rendering errors.
any combination without card1, the monitors turn on and show sway with a lot of rendering errors
any combination that starts with card1, sway crashes immediately giving the error messages in my original post
any combination with card1, but starting with another freezes my laptop display and shows sway on one of the monitors, with rendering errors. I have to use STRG-ALT-F3 or something to get to another shell and kill sway in order to continue.

I have no idea what to make of that behaviour, either.

One last bit of info: a new version of "displaylink" hit AUR today. The behaviour is the same with the old and the new version.

seth · 2025-09-18 19:14:12

I have no clue what to make of that. Any ideas?

Not without seeing it

eglinfo | curl -F 'file=@-' 0x0.st

Also please start a simple X11 session (can be openbox) and post your Xorg log, https://wiki.archlinux.org/title/Xorg#General (it's basically just for that - what monitor is actually attached where and what those three cards are)
Edit: this can easily be on the working mesa version, no need to break your system for that.

Last edited by seth (2025-09-18 19:14:42)

jabbo · 2025-09-18 20:26:23

Here's the respective outputs of eglinfo for now.

eglinfo output of the working setup with the downgraded mesa: https://0x0.st/KTB5.txt
eglinfo output of the broken setup with the current mesa drivers: https://0x0.st/KTBE.txt

Will add the Xorg log as soon as I can reboot the machine.
Thanks for your help!

seth · 2025-09-18 21:00:51

Mesa - 25.1.2-1 requires llvm 19, which is why with the isolated downgrade you're getting

MESA-LOADER: failed to open dri: libLLVM.so.19.1: cannot open shared object file: No such file or directory (search paths /usr/lib/gbm, suffix _gbm)

, mesa is effectively broken.
What happens if you install https://archlinux.org/packages/extra/x8 … vm19-libs/ ?

jabbo · 2025-09-19 06:54:56

seth wrote:

What happens if you install https://archlinux.org/packages/extra/x8 … vm19-libs/ ?

Installing llvm breaks my workaround.
So mesa 25.1.2 + llvm behaves like mesa 25.3.

So... do I understand this correctly? My multihead setup only works if mesa is broken? And if I fix it by upgrading mesa or installing llvm, I paradoxically break my environment?

And here is the Xorg log, you asked for: https://0x0.st/KT_a.txt
Edit: Oh, and for context: in the X-Session (XFCE) the external monitors didn't respond at all. Xfce started, but used only the display of my laptop.

Thanks for all the effort you put into this, seth. Much appreciated.

Last edited by jabbo (2025-09-19 07:01:05)

seth · 2025-09-19 08:21:18

That's not /var/log/Xorg.0.log - don't grep, the link is only to explain where to find the log (depending on how you start X11) itfp.
For DisplayLink on X11 you'll likely also need https://aur.archlinux.org/packages/displaylink/ - see https://wiki.archlinux.org/title/Displa … xx_Devices for details

But yeah, this doesn't hinge on the mesa version but running dri-less in software emulation or sth. like that.
Your workaround isn't viable at all.

Use the current mesa version, post your xorg log, try to use the x11 evdi driver.
We'll first establish that the system principally ok and then see whether and how to extend that to the (officially unsupported) sway system.

jabbo · 2025-09-19 15:03:44

seth wrote:

That's not /var/log/Xorg.0.log - don't grep, the link is only to explain where to find the log (depending on how you start X11) itfp.

Ah, sorry. Misunderstood you there.

seth wrote:

We'll first establish that the system principally ok and then see whether and how to extend that to the (officially unsupported) sway system.

Thank you so much. Ok, here we go:

mesa up to date
displaylink is installed, enabled and running
evdi-dkms is installed and "dkms status" reports it as loaded
Xorg.0.log: https://0x0.st/KT4l.txt
Xorg.1.log: https://0x0.st/KT4U.txt

In this, xfce doesn't activate the external monitors, nor do they show up in xrandr --listproviders

Providers: number : 1
Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel

seth · 2025-09-19 15:42:21

Remove xf86-video-intel and any config referencing it

grep -ri intel /{etc,usr/share}/X11/xorg.conf*

Did you add the /etc/X11/xorg.conf.d/20-evdi.conf from the wiki?

Edit: and then please post the updated X11 log.

Last edited by seth (2025-09-19 15:43:06)

jabbo · 2025-09-20 06:46:56

seth wrote:

Remove xf86-video-intel and any config referencing it

For X, that did the trick. XFCE is working with both external monitors, now.

seth wrote:

Did you add the /etc/X11/xorg.conf.d/20-evdi.conf from the wiki?

Yep, present.

- Xorg.0.log: https://0x0.st/KTEC.txt
- Xorg.1.log: https://0x0.st/KT4U.txt

seth · 2025-09-20 08:20:20

There're the three cards:

[    35.235] (II) Platform probe for /sys/devices/pci0000:00/0000:00:02.0/drm/card1
[    35.267] (II) Platform probe for /sys/devices/platform/evdi.0/drm/card0
[    35.268] (II) Platform probe for /sys/devices/platform/evdi.1/drm/card2

Next to the eDP on the intel chip there're two evdi outputs.

You ultimately want

WLR_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0:/dev/dri/card2 sway

* Is the status quo a regression, ie. has this *ever* worked w/ sway w/o breaking MESA?
* Did you previously have https://aur.archlinux.org/packages/displaylink installed and enabled?
* Does "LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe sway" work, resp. what kind of problems do you get (original errors, visual artifacts)
* Do eg. hyprland work or weston work?
* Can you please post the entire sway log you now get (w/ proper mesa and broken sway)

References:
https://github.com/swaywm/sway/issues/6256
https://github.com/swaywm/wlroots/issues/1823
https://github.com/swaywm/sway/issues/8105

jabbo · 2025-09-22 11:02:20

seth wrote:

* Is the status quo a regression, ie. has this *ever* worked w/ sway w/o breaking MESA?

I guess not. But I only became aware that I had been running my system with broken MESA when you pointed it out to me. All I experienced was that after some update sway crashed on start and that downgrading mesa (and by that breaking it again) made it start.
So no, probably that has never worked without breaking MESA, but I'm not sure.

seth wrote:

* Did you previously have https://aur.archlinux.org/packages/displaylink installed and enabled?

Yes

seth wrote:

* Does "LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe sway" work, resp. what kind of problems do you get (original errors, visual artifacts)

I ran:

LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe sway --unsupported-gpu

It does crash with the same error as in my original post, plus on additional line:
"libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device."

seth wrote:

* Do eg. hyprland work or weston work?

If I start hyprland from the command line, it works and brings up both external monitors. When starting the lightdm session, it freezes. But that might be an issue with that session file, I haven't looked into it, yet
Weston does start as well, but does not fire up the external monitors. But that might well be a config issue.
I have started both hyprland and weston with next to no config.

seth wrote:

** Can you please post the entire sway log you now get (w/ proper mesa and broken sway)

OK, here's the output of "WLR_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0:/dev/dri/card2 sway -d --unsupported-gpu": https://0x0.st/KASv.txt

Thanks, once more.

seth · 2025-09-22 19:42:13

So status quo, evdi works on X11 and hyprland, but not sway (we'll kinda ignore weston as being mostly a tech demo, feel free to try labwc or so)?

All I experienced was that after some update sway crashed on start and that downgrading mesa (and by that breaking it again) made it start.

Ok, but sway very much *might* have worked with an intact mesa previous to that downgrade? Do you somewhat remember when that was and check the pacman log what actually updated during that time (and whether eg. sway or wlroots was part of that)?

jabbo · 2025-09-22 21:22:52

seth wrote:

So status quo, evdi works on X11 and hyprland, but not sway

Yes, that's the situation.

seth wrote:

Ok, but sway very much *might* have worked with an intact mesa previous to that downgrade? Do you somewhat remember when that was [...]?

Sorry, no I don't remember. Or rather, I probably didn't notice. The only change that I noticed was when mesa 25.1.3 came along and my sway setup stopped working with my docking station.
That it probably only ever worked because my mesa was broken even before that? I had no idea. Feel a bit stupid. But I guess, I don't do enough graphics intensive work...
I'm sorry that I can't provide any more useful leads for all the diligent detective work your putting in, here.
Thanks for that. Thanks for trying, even if this turns out to be a dead end. Much appreciated, seth.

seth · 2025-09-25 14:54:04

Problem should be

00:00:01.940 [DEBUG] [wlr] [backend/drm/renderer.c:17] Creating multi-GPU renderer
00:00:01.940 [INFO] [wlr] [render/egl.c:205] Supported EGL client extensions: EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11 EGL_EXT_platform_x11 EGL_EXT_platform_device EGL_MESA_platform_surfaceless EGL_EXT_explicit_device EGL_KHR_platform_wayland EGL_EXT_platform_wayland EGL_KHR_platform_gbm EGL_MESA_platform_gbm EGL_EXT_platform_xcb
00:00:01.940 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list.
"
00:00:01.940 [ERROR] [wlr] [EGL] command: eglQueryDevicesEXT, error: EGL_BAD_ALLOC (0x3003), message: "EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list.
"
00:00:01.940 [ERROR] [wlr] [render/egl.c:490] Failed to get DRM device: No such device
00:00:01.940 [DEBUG] [wlr] [render/egl.c:546] DRM device '/dev/dri/card2' has no render node, falling back to primary node
MESA-LOADER: failed to retrieve device information

And there's no indication of the evdi devices in the eglinfo provided at https://bbs.archlinux.org/viewtopic.php … 8#p2262388
Has that changed resp. was that eglinfo drawn w/ the DL outputs connected?

jabbo · 2025-10-11 08:29:51

Sorry for the late reply. For some reason I failed to notice your post.
But - without me doing anything - my setup now works, probably by some upgrade in wlroots, sway etc. That's why I came here.

seth wrote:

And there's no indication of the evdi devices in the eglinfo provided at https://bbs.archlinux.org/viewtopic.php … 8#p2262388
Has that changed resp. was that eglinfo drawn w/ the DL outputs connected?

Yes, eglinfo was run with the outputs connected.

So, what do we do now? Should I just mark this as solved because the thread because the problem went away seemingly miraculously?

seth · 2025-10-11 12:00:41

Keep an eye on it, make sure everything's still HW accelerated and when you're confident this isn't just a fluke yes, please. Mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2025-09-17 17:18:32