[PR #33] [CLOSED] refactor: stop advertising legacy wl_drm when dmabuf v4 feedback is available #34

New issue

Closed

opened 2026-10-15 12:47:44 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:47:44 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/33
Author: @shrinedogg
Created: 6/11/2026
Status: ❌ Closed

Base: stable ← Head: fix/optional-wl-drm

📝 Commits (1)

9aeeb10 fix: only advertise legacy wl_drm when dmabuf v4 feedback is unavailable

📊 Changes

1 file changed (+40 additions, -14 deletions)

View changed files

📝 wayland-display-core/src/comp/mod.rs (+40 -14)

📄 Description

What this changes

wl_drm is a legacy Mesa protocol, superseded by zwp_linux_dmabuf_v1 v4 feedback for render-device discovery — Mutter and KWin have already dropped it entirely. Today the compositor advertises both wl_drm and dmabuf v4 default feedback at the same time, which is redundant.

This PR stops advertising wl_drm when the dmabuf v4 default-feedback global is created successfully:

skip create_drm_global when v4 default feedback is available;
keep wl_drm on the dmabuf v3 fallback path, where clients still need it for device discovery;
add an opt-in escape hatch for legacy clients — GST_WAYLAND_DISPLAY_ADVERTISE_WL_DRM=1 restores the previous behavior.

Scope / history (please read)

I originally opened this believing it fixed a nested-wlroots (sway) startup abort — assert(wl->drm_render_name == NULL) at backend/wayland/backend.c:311. Per @JBailes's review, that justification does not hold up: wlroots 0.19 already handles wl_drm and dmabuf-v4 feedback coexisting (it destroys the wl_drm global and resets drm_render_name to NULL before reading the device from the v4 main_device), and the logs I attached don't actually contain that assert. Thanks for the careful read.

So, taking @JBailes's suggestion to split this up:

This PR no longer claims to fix that crash. It stands on its own as a cleanup that matches what Mutter/KWin already did and removes a redundant legacy global, with an env opt-out for old clients.
The problem actually visible in my logs is separate and unrelated to wl_drm: inside the session pod, wlroots can't resolve the main_device dev_id advertised in the v4 feedback (render/wlr_renderer.c:249 drmGetDevices2 failed, backend/wayland/backend.c:166 drmGetDeviceFromDevId failed), and sway later dies on output.c:525 Failed to commit output WL-1 (no outputs connected). That's a DRM-node-in-namespace issue; I'll investigate and raise it on its own rather than bundling it here.

Testing

Build only (cargo check) — this is purely a protocol-advertisement change and I'm intentionally not attaching a crash-fix claim to it. Happy to add the env hatch behind a different name or default if you'd prefer.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/gst-wayland-display/pull/33 **Author:** [@shrinedogg](https://github.com/shrinedogg) **Created:** 6/11/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `fix/optional-wl-drm` --- ### 📝 Commits (1) - [`9aeeb10`](https://github.com/games-on-whales/gst-wayland-display/commit/9aeeb104a9328245c2419e1b25beed84d727156e) fix: only advertise legacy wl_drm when dmabuf v4 feedback is unavailable ### 📊 Changes **1 file changed** (+40 additions, -14 deletions) <details> <summary>View changed files</summary> 📝 `wayland-display-core/src/comp/mod.rs` (+40 -14) </details> ### 📄 Description ## What this changes `wl_drm` is a legacy Mesa protocol, superseded by `zwp_linux_dmabuf_v1` v4 feedback for render-device discovery — Mutter and KWin have already dropped it entirely. Today the compositor advertises **both** `wl_drm` and dmabuf v4 default feedback at the same time, which is redundant. This PR stops advertising `wl_drm` when the dmabuf v4 default-feedback global is created successfully: * skip `create_drm_global` when v4 default feedback is available; * keep `wl_drm` on the dmabuf **v3** fallback path, where clients still need it for device discovery; * add an opt-in escape hatch for legacy clients — `GST_WAYLAND_DISPLAY_ADVERTISE_WL_DRM=1` restores the previous behavior. ## Scope / history (please read) I originally opened this believing it fixed a nested-wlroots (sway) startup abort — `assert(wl->drm_render_name == NULL)` at `backend/wayland/backend.c:311`. Per @JBailes's review, **that justification does not hold up**: wlroots 0.19 already handles `wl_drm` and dmabuf-v4 feedback coexisting (it destroys the `wl_drm` global and resets `drm_render_name` to `NULL` before reading the device from the v4 `main_device`), and the logs I attached don't actually contain that assert. Thanks for the careful read. So, taking @JBailes's suggestion to split this up: * **This PR no longer claims to fix that crash.** It stands on its own as a cleanup that matches what Mutter/KWin already did and removes a redundant legacy global, with an env opt-out for old clients. * The problem actually visible in my logs is **separate** and unrelated to `wl_drm`: inside the session pod, wlroots can't resolve the `main_device` dev_id advertised in the v4 feedback (`render/wlr_renderer.c:249 drmGetDevices2 failed`, `backend/wayland/backend.c:166 drmGetDeviceFromDevId failed`), and sway later dies on `output.c:525 Failed to commit output WL-1` (no outputs connected). That's a DRM-node-in-namespace issue; I'll investigate and raise it on its own rather than bundling it here. ## Testing Build only (`cargo check`) — this is purely a protocol-advertisement change and I'm intentionally **not** attaching a crash-fix claim to it. Happy to add the env hatch behind a different name or default if you'd prefer. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-15 12:47:44 +00:00

bsakaguchi referenced this issue

2026-10-15 12:47:44 +00:00

[PR #34] [CLOSED] feat(waylandsrc): add await-listener to defer caps negotiation until a consumer connects #35

bsakaguchi closed this issue

2026-10-15 12:47:44 +00:00

bsakaguchi referenced this issue

2026-10-15 12:47:47 +00:00

[PR #35] [CLOSED] NV12 in compositor + late dmabuf→CUDA #38