Hi Daniel, Many thanks for your detailed explanation. This helps a lot! I will look into your suggested approach of using udmabuf.
Regards, Oliver -----Original Message----- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Daniel Stone Sent: Wednesday, March 25, 2020 12:04 PM To: Wohlmuth, Oliver <oliver.wohlm...@socionext.com> Cc: wayland-devel@lists.freedesktop.org Subject: Re: Getting Weston to use DRM/KMS planes Hi Oliver, On Wed, 25 Mar 2020 at 10:31, Wohlmuth, Oliver <oliver.wohlm...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
