Add support to dma-buf feedback

Dma-buf feedback implementation

This is Weston's implementation of wayland-protocols!8 (merged). It's still a WIP. If you want to know more details about how client/compositor should behave, please take a look at the protocol MR.

The code is based on previous work of @ascent: !397 (closed)

Default dma-buf feedback

In GL-renderer, we use the extension EGL_EXT_device_drm_render_node to find the main device of the default dma-buf feedback. If we can find it, we create the default dma-buf feedback for the compositor. The default feedback has only one tranche, with the target device being the main device. To populate the formats/modifiers of this tranche we use EGL extension EGL_EXT_image_dma_buf_import_modifiers.

Per-surface dma-buf feedback

Each time we create a surface in compositor_create_surface() and the default dma-buf feedback is present in the compositor, we create the dma-buf feedback object of the surface. The main device of the per-surface feedback is the same of the one used by the default feedback. Then we create a tranche for this same device, let's call it renderer tranche. It has the same content of the tranche that has been created for the default feedback.

When the repaint loop starts, we can gather better information for the per-surface feedback that we have.

• If the view ends up in the renderer instead of a plane, we check if this happened only because of the format/modifier of the fb. If that's the case, we create a new tranche for the per-surface feedback, the scanout tranche. It contains the union of formats/modifiers supported by primary and overlay planes. After that we resend the per-surface dma-buf feedback of this surface.

• If the reason why the view didn't up in a KMS plane is not related to format/modifier (for instance, the view may be occluded by another view), we remove the scanout tranche and resend the dma-buf feedback, as we want to hint the client to pick a format/modifier optimal for the renderer.

It's important to mention that we don't re-send the feedback immediately, we wait until the scene reaches certain stability.

Preference of tranches

Each dma-buf feedback object has a list of tranches. Each tranche has a certain preference. For now we have only 2 preferences: scanout and renderer. Scanout has a higher preference value and so scanout tranches always comes first in the list. In the future we may have more preferences.

Flags

For now the only flag in the protocol is scanout. In this case, direct scanout can be used by the client. Do not confuse this flag (which is part of the protocol) with the preference that we've described above (which is internal to Weston).

Sending the dma-buf feedback

These are the events we send for a certain dma-buf feedback object. It's important to mention that the protocol does not enforce a certain order:

- format table event (when it changes)
- main device event
- for each tranche
        - target device event
        - flags event
        - tranche formats events (array of indices of format/modifier pairs in the most recent format table sent)
        - tranche done event
- done event

Testing

The code has been tested on Intel and AMD desktops, and also on Rockpi4 (running Panfrost).

To test it by yourself, just start Weston using the DRM-backend and run the simple-dmabuf-feedback client.