New WPE API and dealing with DMA-BUFs on lacking boards

[q66]

Recently we've been dealing with getting the new WPE API working on some boards, notably e.g. the Realtek board without fully functional drivers for DMA-BUF usage. Some discussion happened in private but I was asked to create an issue here.

So for reference, below are the changes we've done to allow the Realtek board to work. The initial assessment was done using a testbed application, which is a smaller program that emulates some of the requirements for WPE. Using this application, we found how to perform the initialization in a working way, before moving on to replicating this in WPE.

The testbed can be found here: https://github.com/Igalia/wpe-testbed-wayland

A sample command line for the testbed application that draws and works on the Realtek board (this draws an animated checkerboard sample):

$ wpe-testbed-wayland --drm-node-ipu /dev/dri/card0 --egl-platform default --opaque --dmabuf-tiles --tiles 1 --tile-width 512 --tile-height 512 --rbo --fence

Changes done to general buildroot environment:

• Ensure the driver SDK provides libgbm pkg-config file and libgbm.so symlink
  • It already provides the API including header files (based on an older version of Mesa)
• Minor workarounds in various code (can be done as patches) to make up for occasional expectations of newer libgbm
• Enable Westeros so that it is built and can be used instead of the on-device one
  • This also replaces libraries provided by the binary SDK, which is important
  • On-device Westeros does not support the necessary DMA-BUF Wayland protocol
  • Modify the recipe so that the actual runnable Westeros binary is provided
    • This is only for our device testing with standalone WPE; a WPEFramework-based solution would not use that
• Modify some of the Buildroot recipes to enable building (e.g. WPEBackend-FDO) with the provided binary driver SDK
• Provide scripts to perform launching of WPE with the correct environment set up

Changes done to WPE (to be upstreamed):

• The prior upstream changes we've done over time to accomodate older GBM implementations
• Enablement of PlatformDisplayDefault for WPE (already enabled for GTK)
  • This is to bypass PlatformDisplayGBM, which invokes APIs that do not work with the userland driver + kernel combo
    • This is for instance anything using EGL_PLATFORM_GBM_KHR such as eglGetPlatformDisplay with gbm_device *; these APIs fail
    • However, we can instantiate a valid display by using eglGetDisplay(EGL_DEFAULT_DISPLAY) which is what PlatformDisplayDefault does
      • After that, using DMA-BUFs actually works, independently from that (we just need to get past this initialization stage)
  • Fill in some missing paths that were not being handled with PlatformDisplayDefault
    • Most notably AcceleratedSurfaceDMABuf creation and swapchain support
• Environment override necessary to pick the correct render node
  • Using /dev/dri/card0 for render, as there is no dedicated render node with the Realtek kernel
  • Another override needed to avoid instantiating PlatformDisplayGBM when render node is forced (this fails)
• Environment override necessary to pick the correct DMA-BUF format
  • The Westeros compositor supports zwp_linux_dmabuf_v1 for passing of buffers, but not zwp_linux_dmabuf_feedback_v1
    • This is necessary for format negotiation, but we can bypass it by forcing a known format instead

I have a suspicion that similar but different changes may also allow us to set up the new WPE API with e.g. the Sagemcom board using the different proprietary Nexus API, but the testbed etc. cannot be used there as regular DMA-BUFs are not being used. it may however help on other boards that can use DMA-BUFs but have similar driver deficiencies.