compositor-drm & MESA dependencies
benjaminfranzke at googlemail.com
Tue Apr 12 12:40:14 PDT 2011
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?
> 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.
More information about the wayland-devel