[PR #55] [MERGED] fix(egl): drop the vestigial wl_display bind and its misleading log #56

New issue

Closed

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

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/55
Author: @JBailes
Created: 8/16/2026
Status: ✅ Merged
Merged: 8/16/2026
Merged by: @JBailes

Base: feat/vulkan-encode ← Head: fix/drop-vestigial-egl-bind

📝 Commits (1)

c9001bd fix(egl): drop the vestigial wl_display bind and its misleading log

📊 Changes

1 file changed (+13 additions, -6 deletions)

View changed files

📝 wayland-display-core/src/comp/mod.rs (+13 -6)

📄 Description

bind_wl_display's only product is the EGLBufferReader behind BufferType::Egl, and nothing reads it. EGLBufferReader and import_egl_buffer appear nowhere in the crate; the only client-buffer import routes are import_dmabuf at handlers/dmabuf.rs:20 and handlers/wl_drm.rs:18.

No client can reach that path either. smithay's buffer_type() resolves Dma, Shm and SinglePixel before Egl, and every buffer-carrying global this compositor advertises lands in one of the first three. Its own wl_drm initialises the WlBuffer with a Dmabuf as user data, so mesa's wl_drm buffers resolve as Dma, which is why the comment below already notes wl_drm does not need the bind. That is a reading of the dispatch order rather than an observation of a client: tests/fixture.rs:38 runs RenderTarget::Software, so no test reaches this branch at all.

The bind therefore enabled an import path with no possible client, and its only observable effect was the log. On render nodes lacking EGL_WL_bind_wayland_display it printed "Failed to initialize EGL hardware-acceleration" on every start, reading as a fallback to software rendering that never happened. The success arm claimed acceleration had been enabled by a call that enables nothing used. Removing both removes the confusion at its source instead of rewording it.

Dropping the call also makes the mut on renderer redundant, since nothing else in that scope takes it mutably before it moves into State.

_{🔄 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/55 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 8/16/2026 **Status:** ✅ Merged **Merged:** 8/16/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `feat/vulkan-encode` ← **Head:** `fix/drop-vestigial-egl-bind` --- ### 📝 Commits (1) - [`c9001bd`](https://github.com/games-on-whales/gst-wayland-display/commit/c9001bd243fc5d654b7b4288d00e854f4bbca2d9) fix(egl): drop the vestigial wl_display bind and its misleading log ### 📊 Changes **1 file changed** (+13 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `wayland-display-core/src/comp/mod.rs` (+13 -6) </details> ### 📄 Description `bind_wl_display`'s only product is the `EGLBufferReader` behind `BufferType::Egl`, and nothing reads it. `EGLBufferReader` and `import_egl_buffer` appear nowhere in the crate; the only client-buffer import routes are `import_dmabuf` at `handlers/dmabuf.rs:20` and `handlers/wl_drm.rs:18`. No client can reach that path either. smithay's `buffer_type()` resolves `Dma`, `Shm` and `SinglePixel` before `Egl`, and every buffer-carrying global this compositor advertises lands in one of the first three. Its own `wl_drm` initialises the `WlBuffer` with a `Dmabuf` as user data, so mesa's wl_drm buffers resolve as `Dma`, which is why the comment below already notes wl_drm does not need the bind. That is a reading of the dispatch order rather than an observation of a client: `tests/fixture.rs:38` runs `RenderTarget::Software`, so no test reaches this branch at all. The bind therefore enabled an import path with no possible client, and its only observable effect was the log. On render nodes lacking `EGL_WL_bind_wayland_display` it printed "Failed to initialize EGL hardware-acceleration" on every start, reading as a fallback to software rendering that never happened. The success arm claimed acceleration had been enabled by a call that enables nothing used. Removing both removes the confusion at its source instead of rewording it. Dropping the call also makes the `mut` on `renderer` redundant, since nothing else in that scope takes it mutably before it moves into `State`. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

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