The ClientBuffer type is empty now, most of the things have been
upstreamed to the GraphicsBuffer type. So let's drop it to simplify the
type hierarchy.
ClientBufferIntegration was introduced to work around the fact that some
client buffers are not created by us.
In addition to that, DisplayPrivate::registerClientBuffer() was
introduced to register client buffers created by us.
This change get rids of the ClientBufferIntegration type and further
simplifies the ClientBuffer type to make wayland-specific client buffer
code less messier.
As of nowadays, most clients have switched to the linux-dmabuf protocol,
except Xwayland, which still needs the wl-drm protocol.
On the other hand, we would like to unify some buffer handling code.
There are a few options:
- drop the support for wl-drm protocol. Not doable, because Xwayland
still needs it, even though it uses the linux dmabuf feedback protocol
too
- re-implement the wl-drm protocol
- re-implement the minimal part of the wl-drm protocol needed by
Xwayland
This change goes after the third option. Only the node name and the
capabilities will be sent. The buffer factory requests are not
implemented, but they can be if we discover that some clients need them.
This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
Currently, the BufferInterface encapsulates all the kinds of client
buffers. This has become a somewhat annoying issue as we want to
reference the shm pool if a shm buffer is destroyed, or have custom
buffer readiness logic for linux dma-buf client buffers.
Implementing all of that with the current abstractions will be
challenging as there's no good separation between different client
buffer types.
This change splits the BufferInterface class in three sub-classes -
DrmClientBuffer, LinuxDmaBufV1ClientBuffer, and ShmClientBuffer.
In addition to that, this change fixes the broken buffer ref'ing api.
