A client can specify the following flags when creating a linux dmabuf
client buffer:
- y_invert
- interlaced
- bottom_first
Only the y_invert flag is supported by kwin. The interlaced and the
bottom_first flags are ignored. On the other hand, most clients don't
specify the dmabuf flags. For example, neither EGL nor Vulkan WSIs
use the y_invert flag.
The y_invert flag is undesired because it also blocks optimizations such
as direct scanout because DRM assumes that the origin is in the top left
corner.
Therefore, this change drops the support for linux dmabuf flags. From
the protocol perspective, this is fine. It can be viewed as buffer
import failing with the specified flags.
LinuxDmaBufV1ClientBuffer contains properties (formats, and flags) that
are not available in the base GraphicsBuffer type and there's no reason
to move it there.
In order to get rid of those properties (and eventually hide the
LinuxDmaBufV1ClientBuffer type from the public api), this change adds a
DmaBufAttributes getter in the GraphicsBuffer.
The debug shader is targeted to help with debugging blurriness when
using fractional scaling.
The shader works as follows:
- if the vertex coordinate has fractional part, the item will be
highlighted with blue color
- if the texture coordinate (in device pixels) has fractional part,
the item will be highlighted with red color
The shader can be toggled by setting the KWIN_SCENE_VISUALIZE=fractional
environment variable.
Taking the address of a reference that's a dereference of a newly created
object is the most possibly confusing way to initialize a std::unique_ptr.
Instead, just pass a std::unique_ptr around to take ownership of
Currently, there exists the separation between the buffers provided by
the clients and the buffers created by the compositor.
In hindsight, this separation is not great because it leads to
specialized code paths in the output backend. For example, we have a
separate code path for direct scanout and presenting composited frame.
But you could view the latter case as "direct scanout of a compositor
buffer".
The main idea behind the buffer type is to provide a base buffer type
for client buffers and composited frame buffers (not drm fbs) that we
could pass around, import as textures, etc.
Some users prefer this over the existing options. It e.g. allows to open
a bunch of links and only then switch to the browser on a different desktop
BUG: 464283
Currently, on X11, when activating a window that is not on the current desktop we allow this
only if focus stealing protection is set to none.
If any focus stealing protection is set then activation is denied. That behavior is
unintiutive to the user. When I e.g. click on a notification from a chat app I expect
something to happen, regardless of focus stealing protection.
Remove the special handling of windows on different desktops and only apply the usual
focus stealing prevention checks (based on timestamps etc). This also matches the behavior
on Wayland.
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.
Discards frames sent under the timeframe that was negotiated with the
client. This allows clients to just request the frames that they should
be able to compute.
In particular, explain what all of the the focus stealing prevention
and protection settings do.
My understanding of the different modes comes from reading the code
and code comments in activation.cpp.
CCBUG: 458976
With the dmabuf multi-gpu path, a buffer is imported to the secondary GPU
and presented directly, but importing a buffer that's usable for scanout
is not possible that way on most hardware. To prevent CPU copy from being
needed in those cases, this commit introduces a fallback where the buffer
is imported for rendering only, and then copied to a local buffer that's
presented on the screen.
CCBUG: 452219
CCBUG: 465809
