You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In render_frame_background() a buffer is created, attached and destroyed before it's surface is committed. Swaylock seems to expect the compositor to render using this buffer (if it doesn't the surface is unmapped and nothing is displayed.
It's unclear to me if this behavior is supposed to be allowed by the protocol. It is possible for compositors to support it at a technical level, but neither Weston or Mir do currently (I ran into this trying to add lock screen support to Mir). I think it would be best to not destroy the buffer until after it has been committed.
This issue was introduced in 1d3e62c, and has not yet been present in a release.
The text was updated successfully, but these errors were encountered:
Right, my understanding of the spec is that clients are allowed to destroy buffers after wl_surface.attach, but I think many compositors don't support that...
This wasn't obvious to me from reading the spec, and Weston doesn't support it. Is there any particular wording in the spec or other source you can point to that says that's allowed?
In render_frame_background() a buffer is created, attached and destroyed before it's surface is committed. Swaylock seems to expect the compositor to render using this buffer (if it doesn't the surface is unmapped and nothing is displayed.
It's unclear to me if this behavior is supposed to be allowed by the protocol. It is possible for compositors to support it at a technical level, but neither Weston or Mir do currently (I ran into this trying to add lock screen support to Mir). I think it would be best to not destroy the buffer until after it has been committed.
This issue was introduced in 1d3e62c, and has not yet been present in a release.
The text was updated successfully, but these errors were encountered: