This adds support for LinuxDmabufUnstableV1Interface in kwin.
I asked Marco to test it with a driver that supports modifiers, and he confirmed that it works.
I have also checked that kwin still works with drivers that don't support modifiers.
Test results before (6 failures):
The following tests FAILED:
30 - kwin-testLockScreen (Failed) 39 - kwin-testPointerInput (Failed) 57 - kwin-testSceneOpenGL-waylandonly (Failed) 71 - kwin-testKeyboardLayout (Failed) 74 - kwin-testKeymapCreationFailure-waylandonly (Failed) 88 - kwin-testColorCorrectNightColor-waylandonly (Failed)
Test results after (8 failures):
The following tests FAILED:
30 - kwin-testLockScreen (Failed) 39 - kwin-testPointerInput (Failed) 59 - kwin-testSceneOpenGLES-waylandonly (Failed) 60 - kwin-testNoXdgRuntimeDir (Failed) 61 - kwin-testNoXdgRuntimeDir-waylandonly (Failed) 71 - kwin-testKeyboardLayout (Failed) 72 - kwin-testKeyboardLayout-waylandonly (Failed) 74 - kwin-testKeymapCreationFailure-waylandonly (Failed)
I'm not sure what to make of this, but at least some of these failures are spurious.
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.
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.
No, it will not. It will leave a dangling pointer in the wl_resource, which will result in a double-free when the client deletes the buffer. Or a segfault the next time it tries to attach the buffer to a surface.
I will expand on this in a separate comment.
Do typedefs for KWayland::Server::LinuxDmabuf in files where you use it more than once.
Name should be more descriptive in relation to functionality, also it's not a signal, so "aboutTo" imo not recommended.
Why QLinkedList? It should be no better than QList for the removeOne call. For this better use QSet.
Why is it necessary to export?
That is the question I'm asking.
I believe the use of QList is discouraged in new code, but you are right about QSet being a better choice in this case.
I guess it isn't. I was thinking at the time that someone might want to use this class in a class derived from AbstractEglBackend or AbstractEglTexture.
We would need to create a separate EGL image and a separate texture for each plane.
Thanks for the explanation @fredrik. It wasn't clear to me how multi-planes buffers are handled (also that it's the same notion as for hw-planes is annoying!).
Until we support multi-plane buffers shouldn't we then filter out all multi-plane formats in the supportedFormats call such that the client does not even try to use these instead of just failing with null here?