compositor-drm & MESA dependencies

[Marcus Lorentzon]

On 04/12/2011 09:40 PM, Benjamin Franzke wrote:
> 2011/4/12 Marcus Lorentzon<marcus.xm.lorentzon at stericsson.com>:
>    
>> Hi,
>> 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
>> extension.
>>
>>      
> 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:
> http://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_drm_image.txt
>
> 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
>> compositor?
>>
>>      
> 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 
libwayland-egl?

/BR
/Marcus