Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wl_buffer destroyed before surface committed #299

Closed
wmww opened this issue Jun 9, 2023 · 3 comments · Fixed by #300
Closed

wl_buffer destroyed before surface committed #299

wmww opened this issue Jun 9, 2023 · 3 comments · Fixed by #300

Comments

@wmww
Copy link
Contributor

wmww commented Jun 9, 2023

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.

@emersion
Copy link
Member

emersion commented Jun 9, 2023

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...

@wmww
Copy link
Contributor Author

wmww commented Jun 9, 2023

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?

@emersion
Copy link
Member

emersion commented Jun 9, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants