compositor-drm & MESA dependencies
marcus.xm.lorentzon at stericsson.com
Wed Apr 13 02:20:08 PDT 2011
On 04/12/2011 09:40 PM, Benjamin Franzke wrote:
> 2011/4/12 Marcus Lorentzon<marcus.xm.lorentzon at stericsson.com>:
>> we run Wayland on a platform without a MESA based EGL. But we still want to
>> run the DRM compositor and use the same EGL/GLES drivers as for QtCompositor
>> (wayland-egl platform with DRM support included). Currently this is not
>> possible without hacking the compositor removing the MESA based code (get
>> display& create scanout EGLimages). So, do you think it would be possible
>> to put the MESA stuff in a separate file with a more generic API like
>> attached sample patch? We will then implement the same functionality using
>> non-MESA extensions.
>> Another option is of course to add fake MESA EGL functions in a separate
>> file, wrapping our egl stuff until there's a standard DRM<->EGL interaction
> The DRM-image code is not really mesa specific, its only specified by mesa.
> What hinders you from implementing the extension, the spec is available here:
> Whats different in your own DRM-image functions, maybe
> EGL_MESA_drm_image can be improved to match your requirements?
Our issue is that we source 3D IP from external company which makes it
hard to get any misc extension. For real products it's probably not a
big deal, but for this type of early adoption it's not a perfect
solution. But I think we should be able to create MESA extension as a
wrapper on top of our EGL for the time being. And second, I didn't
realize the MESA extension was publicly released now :).
Difference in our DRM-image API is that it doesn't ask EGL to allocate
the memory. Instead app use "DRM" directly for allocating buffers. And
then sending the "name/handle" to EGL for wrapping. Just like most
EGLimage extensions wrap existing resources. This makes the export image
step unnessessary, since we already own the buffer, but at the cost of
client transparency. Client needs to know how to allocate the memory. In
that sense the MESA EGL extension is more generic, since we need a
libKMS like API for allocating buffers. Main motivation for this, is
that we can use same buffer allocation API for EGL/GLES as for non EGL
based video/camera sinks.
>> Or what about extending the wayland-egl platform API with functions to
>> handle allocation of scanout buffers, and make use of wayland-egl in drm
> Right, some abstract image-creation API would be helpful in general.
> This'd help porting compositors to APIs like OpenWF Display which
> requires platform-specific image creation.
> Though I think it should be seperate from wayland-egl, as this is
> intended for client side.
Yes, I think there are generic EGL extensions coming in this area. Maybe
someone working with MESA/DRM and is a member of Khronos should take a
look at this before it's released. Especially making sure the
USE_SCANOUT usage flag is included, unless you decide you can reuse
OpenWF Display type of buffers (which should be ok I guess, same target HW).
As for separating wayland-egl from server code. Isn't wayland-egl the
API used already by server in compositor-wayland? Or you just mean that
you don't want any server only API calls made available in this lib?
We are looking at putting the server buffer protocol API in the same
libwayland-egl.so binary as used by clients. But of course the client
platform API is the only exports that should be linked to from client
binaries. Combining the server side buffer protocol in the same binary
as clients use, makes it easier to handle the dependency between these
two. At least until our buffer protocol is nailed down. Where do you put
the MESA server side marshaling code for drm buffer protocol? libEGL or
More information about the wayland-devel