Odd Behavior With Dual GPUs (AMD + ASPEED) about labwc

[droc12345]

Have you tried setting WLR_DRM_DEVICES to the amd card, before you start labwc?

[epyonavenger]

Have you tried setting WLR_DRM_DEVICES to the amd card, before you start labwc?

Excellent suggestion, doing that does fix the symptoms of the issue, but presents a problem/annoyance in trying to have a standard config across multiple machines.

In the end, I am now listing all entities found in /sys/class/drm, running some tests against them to make sure they're not ASPEED, and if they're not, feeding them into a list for WLR_DRM_DEVICES. I, unfortunately, have not found a simple test to determine if a given device is suitable for Wayland, so just running a deny list vs. something smarter.

On another system I have, with integrated Intel graphics + AMD PCIe, it properly adds both to the list, though now I have to figure out logic for ranking them.

It seems like having whatever is building the auto-detected list ought to drop devices that can't actually do the job, but if that's upstream, I can start a discussion there instead.

[Consolatis]

It seems like having whatever is building the auto-detected list ought to drop devices that can't actually do the job, but if that's upstream, I can start a discussion there instead.

Yes, this seems like a good discussion to have over at https://gitlab.freedesktop.org/wlroots/wlroots/ (and / or the #wlroots IRC channel over at libera). The vkms kernel module along with a usual GPU might be an option to trigger a similar behavior without having access to a ASPEED device.

I assume what happens is that when a device without gles2 driver support is probed the renderer for *all* devices is set to the pixman software renderer, even if none of the outputs of the probed device are in use. An option might be to force the gles2 renderer (WLR_RENDERER=gles2) and teach wlroots to ignore any devices that can not be used with the given renderer rather than to bail out completely or reverting to software rendering for all devices (this might already work today, didn't test).

[droc12345]

What are you using "ast" for? You mention kvm in the 1st post, is it only used for that?
If so, then you could bind the ast module to vfio.

If that's not the case, ie you use ast for other things, then you're stuck with WLR_DRM_DEVICES
but that env var is designed to handle problems like yours.

[epyonavenger]

What are you using "ast" for? You mention kvm in the 1st post, is it only used for that? If so, then you could bind the ast module to vfio.

"kvm" as in the BMC/IPMI keyboard-video-mouse that it uses to remotely control the computer, not kernel-based virtual machine. I do not log into LabWC over that interface, the experience would be awful, but I do use it to do things on TTY2-6 when I'm away from the machine.

If that's not the case, ie you use ast for other things, then you're stuck with WLR_DRM_DEVICES but that env var is designed to handle problems like yours.

As @Consolatis suggested, I'll see about chatting over in wlroots about it. I think a non-power user would expect the "bad" video devices to either not work (eg. don't bother initializing a display on it, ignore it, use the properly functioning devices) or bail out with an error message (eg. you have no devices except the "bad" one). Failing in the background and degrading the experience on all devices seems like an odd choice.

If that's all outside of LabWC, I (or, I imagine, any admins/moderators) can close this one. Though it might be worth making the error message a little more descriptive, if that part is inside LabWC, so people know that all devices are being set to software rendering, not just the one that failed.

[Consolatis]

I think a non-power user would expect the "bad" video devices to either not work (eg. don't bother initializing a display on it, ignore it, use the properly functioning devices) or bail out with an error message (eg. you have no devices except the "bad" one). Failing in the background and degrading the experience on all devices seems like an odd choice.

That approach will have its own issues when using labwc headless (or really any other wlroots based compositor). Same story for systems that only support software rendering. Did you try the WLR_RENDERER=gles2 variant?

Though it might be worth making the error message a little more descriptive, if that part is inside LabWC, so people know that all devices are being set to software rendering, not just the one that failed.

Labwc only calls wlr_renderer_autocreate() and all the log messages from the top post are from wlroots (and mesa).

[epyonavenger]

That approach will have its own issues when using labwc headless (or really any other wlroots based compositor). Same story for systems that only support software rendering. Did you try the WLR_RENDERER=gles2 variant?

Presumably, if you only supported software rendering (or were being used headless), you'd be fine, as it would not be attempting to find common ground between two very unlike video devices.

I'm mildly curious how this affects the Intel/nVidia laptop systems where the Intel device is usually pretty terrible, and the nVidia one is...well...nVidia, which has its own issues in Wayland (though hopefully not for long). I'll have to see if I've got any machines with that setup to test. Anywho.

Trying with WLR_RENDERER=gles2 I see...

00:00:00.018 [ERROR] [EGL] command: eglQueryDeviceStringEXT, error: EGL_BAD_PARAMETER (0x300c), message: "eglQueryDeviceStringEXT"
00:00:00.018 [ERROR] [EGL] command: eglQueryDeviceStringEXT, error: EGL_BAD_PARAMETER (0x300c), message: "eglQueryDeviceStringEXT"
pci id for fd 17: 1a03:2000, driver (null)
MESA-LOADER: failed to open ast: /usr/lib/dri/ast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
00:00:00.030 [ERROR] [render/egl.c:320] Software rendering detected, please use the WLR_RENDERER_ALLOW_SOFTWARE environment variable to proceed
00:00:00.030 [ERROR] [render/egl.c:572] Failed to initialize EGL context
00:00:00.030 [ERROR] [render/gles2/renderer.c:804] Could not initialize EGL
00:00:00.030 [ERROR] [backend/drm/backend.c:269] Failed to query renderer texture formats
00:00:00.030 [ERROR] [backend/backend.c:221] Failed to create DRM backend

...but it also isn't throwing errors in programs anymore, so that's an improvement. I imagine life could/will get a little more complicated if/when the Vulkan option is more viable, but it's not awful for now.

On my Intel + AMD system, it also seems to work fine (huzzah), though it does make me wonder if there are other hidden beasties that are lurking in this area.

Labwc only calls wlr_renderer_autocreate() and all the log messages from the top post are from wlroots (and mesa).

Roger roger. I will poke around the repo over there some more, maybe there's some obvious logic here I could exploit to do this more gracefully.

That said, I am curious. Beyond error messages on startup, is there a good way to query what backend and/or feature level is in use? Things like wayinfo/wayland-info don't seem to say much.

[Consolatis]

That said, I am curious. Beyond error messages on startup, is there a good way to query what backend and/or feature level is in use?

Other than starting labwc with the -d flag (this also updates the wlroots loglevel) I don't think there is much other insight.

[epyonavenger]

Ok, spent the weekend experimenting. I the solution I came up with, and the gles2 one are alright. I'm still trying to figure out the best way to bring this up with wlroots folks, but the problem clearly isn't here, so I'll close it out.

Much appreciation for the tips and alternate solution. Cheers.