[PR #50] [CLOSED] fix(egl): stop reporting a failed wl_display bind as lost hardware acceleration #51

New issue

Closed

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

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/50
Author: @salty2011
Created: 7/26/2026
Status: ❌ Closed

Base: feat/vulkan-encode ← Head: fix/egl-bind-log-and-unbind

📝 Commits (1)

7a34caa fix(egl): stop reporting a failed wl_display bind as lost hardware acceleration

📊 Changes

1 file changed (+11 additions, -1 deletions)

View changed files

📝 wayland-display-core/src/comp/mod.rs (+11 -1)

📄 Description

One small logging fix around the EGL wl_display bind.

renderer.bind_wl_display() failing is logged as info!("Failed to initialize EGL hardware-acceleration"). That reads as a fallback to software rendering, but the only product of this bind is the EGLBufferReader used by the legacy wl_drm / EGL-image import path. Both client-buffer routes here go through import_dmabuf (handlers/dmabuf.rs, and handlers/wl_drm.rs, since mesa's wl_drm is implemented over dmabuf), so a failed bind disables neither hardware acceleration nor dmabuf import.

On render nodes where the bind always fails, that line appears on every startup. It cost me a long detour chasing a software-rendering fallback that was never happening. Demoted to debug! and reworded to say what is actually unavailable.

The earlier revision of this PR also added an explicit unbind_wl_display() at teardown. Review showed the mechanism I proposed for it was wrong, and a live reproduction confirmed the real cause is overlapping compositor lifetimes, which prompt unbinding does not address. Dropped; details in the comments.

cargo build and cargo fmt --check clean on 43d4c25.

_{🔄 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/50 **Author:** [@salty2011](https://github.com/salty2011) **Created:** 7/26/2026 **Status:** ❌ Closed **Base:** `feat/vulkan-encode` ← **Head:** `fix/egl-bind-log-and-unbind` --- ### 📝 Commits (1) - [`7a34caa`](https://github.com/games-on-whales/gst-wayland-display/commit/7a34caa504e543784e2c132e4f907721c59f2d29) fix(egl): stop reporting a failed wl_display bind as lost hardware acceleration ### 📊 Changes **1 file changed** (+11 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `wayland-display-core/src/comp/mod.rs` (+11 -1) </details> ### 📄 Description One small logging fix around the EGL `wl_display` bind. `renderer.bind_wl_display()` failing is logged as `info!("Failed to initialize EGL hardware-acceleration")`. That reads as a fallback to software rendering, but the only product of this bind is the `EGLBufferReader` used by the legacy wl_drm / EGL-image import path. Both client-buffer routes here go through `import_dmabuf` (`handlers/dmabuf.rs`, and `handlers/wl_drm.rs`, since mesa's wl_drm is implemented over dmabuf), so a failed bind disables neither hardware acceleration nor dmabuf import. On render nodes where the bind always fails, that line appears on every startup. It cost me a long detour chasing a software-rendering fallback that was never happening. Demoted to `debug!` and reworded to say what is actually unavailable. The earlier revision of this PR also added an explicit `unbind_wl_display()` at teardown. Review showed the mechanism I proposed for it was wrong, and a live reproduction confirmed the real cause is overlapping compositor lifetimes, which prompt unbinding does not address. Dropped; details in the comments. `cargo build` and `cargo fmt --check` clean on `43d4c25`. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

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