Concerning the tests: the ones requiring OpenGL work best if module vgem is loaded. That normally makes them pass. The tests regarding keyboard layout need env variable XDG_DEFAULT_LAYOUT being unset or on us.

In D10750#211784, @graesslin wrote:

Concerning the tests: the ones requiring OpenGL work best if module vgem is loaded. That normally makes them pass. The tests regarding keyboard layout need env variable XDG_DEFAULT_LAYOUT being unset or on us.

Those results are with vgem loaded, and XDG_DEFAULT_LAYOUT is not set.

An issue that this patch does not fully address is switching compositing backends at runtime.

Buffers are imported by the scene. The scene allocates and returns a subclassed LinuxDmabuf::Buffer that contains the file descriptors and backend specific objects, such as EGL images. When the compositing backend is destroyed, the EGL images are also destroyed, but the buffers survive. The new backend could use the file descriptors to re-import the buffers, if the buffer class wasn't specific to the old backend.

A possible solution to this is a shared Buffer class (in platformsupport/scenes/common?):

    ...
private:
    ...
    QVector<Plane> planes;
    EGLimage eglImage;
    VkImage vulkanImage;
    VkImageView imageView;
    VkDeviceMemory deviceMemory;
};

Or a SceneBufferData object, created and destroyed by the scene:

private:
    ...
    QVector<Plane> planes;
    SceneBufferData *sceneData;
};

But even with a shared class there are no guarantees that a re-import is possible, since the new backend might not support the same formats and/or modifiers. So I don't know if runtime switching is something that should be expected to work.

Do typedefs for KWayland::Server::LinuxDmabuf in files where you use it more than once.

In D10750#216337, @fredrik wrote:

An issue that this patch does not fully address is switching compositing backends at runtime.

Do we support that at all? The backend is set at startup. Don't think you can change this later on.

In D10750#224860, @romangg wrote:

In D10750#216337, @fredrik wrote:

An issue that this patch does not fully address is switching compositing backends at runtime.

Do we support that at all? The backend is set at startup. Don't think you can change this later on.

That is the question I'm asking.

Any update on this?

In D10750#327333, @zzag wrote:

Any update on this?

I am wondering as well.
This seems like good progress was already done and what is left is some test fixes and polish.
I can only encourage @fredrik and good KWin folks in their endeavor.

In D10750#486570, @romangg wrote:

Multi-plane support is needed. See @fredrik's inline comment on how to do that:

We would need to create a separate EGL image and a separate texture for each plane.
The scene would need to bind each of those textures to separate texture binding points, and we would need to generate and use a shader that samples texels from each plane and performs YUV to RGB conversion.

Going through Weston's code this seems only true for original multi-plane formats, but not for dma-bufs with multiple planes via modifier.
See: https://gitlab.freedesktop.org/wayland/weston/blob/5d7877adfd31956bdad98da4a937059260da1f69/libweston/renderer-gl/gl-renderer.c#L2291

While allowing multi-plane for the former would involve some more fundamental changes to KWin since we when need to save multiple textures per WindowPixmap, doing the modifier multi-plane it seems we just receive a single EGLImage which we can then texture from. At least the following revision works with both weston-simple-dmabuf-egl and weston-simple-dmabuf-drm. And session starts including XWayland (didn't work before).