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

Fix Surface::lock_front_buffer failing when ffi::gbm_surface_lock_front_buffer succeeds #39

Conversation

tronical
Copy link
Contributor

With the proprietary vivante driver it's been observed that gbm_surface_has_free_buffers() fails even though
gbm_surface_lock_front_buffer() succeeds. Since C/C++ based programs like Weston, kmscube, mutter, or Qt's eglfs renderer don't check for has_free_buffers() before lock_front_buffer() and they work with said drivers, work around it by removing the check.

Fixes #36

…nt_buffer succeeds

With the proprietary vivante driver it's been observed that
gbm_surface_has_free_buffers() fails even though
gbm_surface_lock_front_buffer() succeeds. Since C/C++ based programs
like Weston, kmscube, mutter, or Qt's eglfs renderer don't check for
has_free_buffers() before lock_front_buffer() and they work with said
drivers, work around it by removing the check.

Fixes Smithay#36
@Drakulix Drakulix merged commit 754a957 into Smithay:master Mar 20, 2024
16 checks passed
@Drakulix
Copy link
Member

Thanks!

@tronical tronical deleted the simon/vivante-no-free-buffer-check-before-lock-front-buffer branch March 20, 2024 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Surface::lock_front_buffer fails when ffi::gbm_surface_lock_front_buffer succeeds
2 participants