-
Notifications
You must be signed in to change notification settings - Fork 24
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
Linux DMABuf support #17
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ader This patch moves the definitions of ViewBackend and ClientBundle into a separate, internal header. A new exportable interface introduced in a later patch will need access to these symbols.
…Base Preparing for the introduction of new specialized client bundle classes, this patch refactors common members of ClientBundle into a base class ClientBundleBase to allow reuse.
and add its implementation in ClientBundle.
…table_fdo To keep 'wpe_view_backend_exportable_fdo' opaque to C code (it contains C++ class ClientBundleBase), we need these accessors in preparation to introduce the new EGL interface and its corresponding ClientBundle, which will live in a separate source file (to make its compilation optional).
The EGLDisplay passed at initialize() is stored in a private member, and will then be used by the new EGL interface to construct the EGLImageKHR.
This new interface is intended to make the backend easy to use by EGL-based applications. A single callback 'export_egl_image' will provide applications with an already constructed, ready to render EGL image. A side benefit of this is that the actual protocol used by the backend's nested compositor (wl_surface, linux-dmabuf, etc) becomes transparent to the application. This new interface is built conditionally by setting the -DEXPORTABLE_EGL cmake option. It is ON by default.
It has been imported/adapted from libweston's own implementation. In the case of 'linux-dmabuf-unstable-v1-server-protocol.h' and 'drm_fourcc.h', files were imported as-is, and should be kept in sync. The implementation exposes a very simple API: - A linux_dmabuf_setup() function advertises the interface to the global wayland server registry. - Upon an 'attach' event on a Wayland surface, the dmabuf buffer associated with the buffer resource, if any, is queried via the linux_dmabuf_get_buffer() function. If the client chose to use the linux-dmabuf interface, then the buffer resource of the attach event should have a matching dmabuf buffer server side. - With the dmabuf buffer, the wayland server implementation can then query its attributes via linux_dmabuf_get_buffer_attributes(), which contain all necessary information to access the underlying image(s) (e.g, by using API from DRM, GBM or EGL). - Finally, linux_dmabuf_teardown() frees resources. It does not remove the interface from the global registry, though. This interface is designed to be used only once per process. It contains a static global state.
…er object It adds the methods to ClientBundle and ClientBundleEGL. In the former, an assertion is hit because its interface can't support Linux DMA buffers. The latter has just a placeholder, the actual implementation will be added later.
and its implementation in ViewBackend, which just calls exportBuffer() on the ClientBundle.
* We should either bundle the protocol definitions for linux-dmabuf or generate the protocol code at build-time. * But in one way or the other, we should include that code inside the WPEBackend-fdo library to not end getting undefined symbol errors. * This patch bundles the file that has been generated by running: $ wayland-scanner public-code \ /path/to/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \ linux-dmabuf-protocol.c
Move the wpe_view_backend_exportable_fdo struct definition and the static view_backend_exportable_fdo_interface implementation into the view-backend-exportable-fdo.h header. This simplifies the creation of wpe_view_backend_exportable_fdo objects. C linkage is not used anymore for those two, as it is not for the removed wpe_view_backend_exportable_fdo_new() and wpe_view_backend_exportable_fdo_get_client_bundle() functions.
…o view-backend-exportable-private.{cpp,h}.
Changes to new-fdo-egl-iface
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.