| Summary: | www-client/firefox-131.0: [26684] Wayland Proxy [0x7f17367979b0] Error: WaylandProxy::SetupWaylandDisplays(), Missing Wayland display, WAYLAND_DISPLAY is empty | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Mair-Keimberger (mm1ke) <mmk> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | mmk |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
Michael Mair-Keimberger (mm1ke)
2024-10-04 19:43:27 UTC
What DE/WM are you using? IIRC there's been trouble detecting wayland when in sway, but something like KDE Plasma works. Also in general, firefox+mold doesn't seem to be pair greatly recently. Not saying it's causing this, but not fully counting it out either. Oh, I see. Yes I'm running sway on my computer :/ Anything i can try here? Disabling mold didn't help unfortunately. Nope, even in the earlier bug (which you reported I believe) you said it just suddenly started working. I don't use wayland and have no idea how it works, but only sway seems to be the problematic WM when it comes to compiling firefox with pgo. There's probably something that needs to be written in the virtwl() function regarding sway - like sway could replace tinywl, but I can't test it so someone needs to provide a working patch. This could be relevant: 00:00:00.000 [1;34m[backend/backend.c:350] Loading user-specified backends due to WLR_BACKENDS: headless[0m 00:00:00.000 [1;34m[backend/headless/backend.c:67] Creating headless backend[0m 00:00:00.000 [1;34m[util/env.c:25] Loading WLR_RENDERER option: vulkan[0m 00:00:00.000 [1;90m[render/wlr_renderer.c:118] Opening DRM render node '/dev/dri/renderD128'[0m 00:00:00.000 [1;31m[render/wlr_renderer.c:121] Failed to open '/dev/dri/renderD128': Permission denied[0m 00:00:00.000 [1;31m[render/wlr_renderer.c:192] Cannot create Vulkan renderer: no DRM FD available[0m 00:00:00.000 [1;31m[render/wlr_renderer.c:272] Could not initialize renderer[0m 00:00:00.000 [1;31m[tinywl.c:921] failed to create wlr_renderer[0m although with +pgo you should have addpredict /dev so it shouldn't be about permissions. I wonder what "no DRM FD available" means. Do you have everything compiled with +dri enabled globally to throw a guess? (In reply to Joonas Niilola from comment #4) > This could be relevant: > 00:00:00.000 [1;34m[backend/backend.c:350] Loading user-specified backends > due to WLR_BACKENDS: headless[0m > 00:00:00.000 [1;34m[backend/headless/backend.c:67] Creating headless > backend[0m > 00:00:00.000 [1;34m[util/env.c:25] Loading WLR_RENDERER option: vulkan[0m > 00:00:00.000 [1;90m[render/wlr_renderer.c:118] Opening DRM render node > '/dev/dri/renderD128'[0m > 00:00:00.000 [1;31m[render/wlr_renderer.c:121] Failed to open > '/dev/dri/renderD128': Permission denied[0m > 00:00:00.000 [1;31m[render/wlr_renderer.c:192] Cannot create Vulkan > renderer: no DRM FD available[0m > 00:00:00.000 [1;31m[render/wlr_renderer.c:272] Could not initialize > renderer[0m > 00:00:00.000 [1;31m[tinywl.c:921] failed to create wlr_renderer[0m > > although with +pgo you should have addpredict /dev so it shouldn't be about > permissions. I wonder what "no DRM FD available" means. Do you have > everything compiled with +dri enabled globally to throw a guess? Actually, i think i know why it might not work anymore :) WLR_RENDERER option: vulkan -> this is something i've changed recently by setting 'export WLR_RENDERER=vulkan' (to try out the vulkan renderer). I'm going to test this. (by removing this export) Thank you for pointing out. Regarding dri. It's not globally enabled per default, but only x11-libs/libvdpau would be rebuild with dri. If the WLR_RENDERER thing wouldn't help, i'll test this. Besides that, would it help to open an issue upstream? Soon sway 1.10 should be released anyway - maybe this improves here too. just successfully emerged firefox -> 'export WLR_RENDERER=vulkan' was the culprit. Sorry for the noise - should have noticed this myself. Glad you figured it out, maybe the ebuild should unset WLR_RENDERER although I'm not sure whether it'd work or not. |
