Skip to content

Make weston_buffer useful [weston_buffer epic part 2]

this MR is based on !766 (merged) which converts the shells to use the solid-colour view work in shell-utils

weston_buffer, as it stands, is pretty useless. Which makes it difficult to implement a program whose primary purpose in life is to display buffers.

When a wl_buffer is first seen, a weston_buffer will be materialised to wrap it, and then passed to the renderer. The renderer is responsible for interpreting the content of the buffer, with the weston_buffer being completely unaware of its content. Furthermore, as soon as a buffer release event is sent to the client, the weston_buffer is discarded; its state only lives in renderer-private state from then on. This is the reason why the scene-graph debug can't tell you anything about SHM buffers when using the GL renderer: the renderer has copied the content and released the buffer, so we can no longer access it.

This series rectifies this by:

  • adding additional information fields to weston_buffer (type, dimensions, format, etc): the core fills these in for SHM and dmabuf buffers, with the GL renderer being called on if we have an opaque EGL buffer, i.e. from the private interface provided by EGL_WL_bind_wayland_display
  • extending the weston_buffer lifetime to its last reference: buffer references are split into content references ('don't release the buffer back to the user as I may still source from it'), and object references ('I don't need the content, but I do need the metadata')
  • adding a solid-colour buffer type: instead of creating a surface and telling the renderer that the surface should be solid, we provide a new solid-colour buffer type which should be attached to the surface

These changes make it possible to remove a lot of special-case handling (surface with no buffer attached, lookaside state storage, surface which is magically solid), and centralises weston_buffer as the place where we get our pixels from, available to all in the core rather than only in renderer-private structures.

pixman-renderer has only seen light rework during this series, with the focus being on gl-renderer (culminating in !768 (merged)).

Edited by Daniel Stone

Merge request reports