Getting Weston to use DRM/KMS planes

[Daniel Stone]

Hi Oliver,

On Wed, 25 Mar 2020 at 10:31, Wohlmuth, Oliver
<Oliver.Wohlmuth at socionext.com> wrote:
> I just started to work with Wayland/Weston, so please forgive me if I ask silly questions.
>
> I’m running Weston (8.0.0) on a custom ARM SoC using the DRM backend. As the OpenGL
> driver is not (yet) adapted for Wayland, I'm running Weston using the '--use-pixman' option.
> This works fine so far.
>
> As our DRM/KMS driver supports several HW planes, I was debugging into the Weston
> code trying to understand how Weston makes use of these HW planes (or what needs
> to be done to get Weston use the HW planes). If I understand the code correctly:
>
> drm_fb_get_from_view()
> {
>     ...
>     if (wl_shm_buffer_get(buffer->resource))
>         return NULL;
>     ...
> }
>
> Weston will never use HW planes for wl_shm_buffer, only for GBM or dmabuf type
> buffer it will be used.
>
>
>
> - Is this correct? What is the reason for this?

That's correct. The reason is that we need to be able to get a KMS
framebuffer object with the pixel content from the client buffer in
it. Effectively, the only way to import client content into a KMS
framebuffer is via dmabuf; KMS has no method of creating framebuffers
from an arbitrary pointer to user memory. And we need a framebuffer
object in order to display anything on a plane.

> - Any suggestions how to get HW planes used without OpenGL rendering?
>
>   Currently I think of patching Weston or implement a Weston client that
>   uses dmabuf buffer. Any hint is appreciated that puts me on the most
>   promising path.

There is no easy out-of-the-box path. The first place to start would
be to patch a client to allocate a dmabuf through the udmabuf kernel
API (the one in the mainline kernel tree, not the external module
living on GitHub), or the vgem driver.

Once you've done that, you will very quickly notice that Weston
doesn't actually support the dmabuf extension when using the Pixman
renderer. This would be possible to implement by implementing the
import_dmabuf, query_dmabuf_formats, and query_dmabuf_modifiers hooks.
You probably only want to declare support the ARGB8888/XRGB8888
formats and the LINEAR modifier. For import_dmabuf, you would want to
call the DMA_BUF_IOCTL_SYNC call on the provided FD, mmap the dmabuf,
then call pixman_image_create_bits_no_clear() to obtain a pixman_image
which the renderer can use to source from the dmabuf's content.

The reason we require the renderer to support dmabuf as well as the
backend is for fallback: in case we can't display the client content
on a KMS plane (which is not guaranteed, as the driver can reject
planes for any reason or limitation), we need to be able to use the
renderer as a fallback to show the content.

Alternately, if your SoC has an Arm Mali GPU, you can use the Panfrost
driver available in the upstream Linux kernel and Mesa GL
implementation, which fully supports dmabuf/Wayland/GBM/etc.

Hope that helps.

Cheers,
Daniel