compositor-drm & MESA dependencies

[Benjamin Franzke]

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?

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

-Ben