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
This property is not used on Wayland because windows are
already not allowed to set their own geometry, so let's
hide it from the UI.
Also update the tooltip to explicitly state which properties
the `Ignore Geometry` property does affect on X11
BUG: 431265
FIXED-IN: 6.0
Tooltips don't work when using the system with touch, and these here are
also a bit annoying with a pointing device since they appear instantly on
hover and take up a lot of space, so they unexpectedly pop up and cover
UI elements a lot.
To improve this, use a KCM.ContextualHelpButton inline in the list items
to show the explanation when clicked or hovered, just like we do in most
other places in other KCMs.
To make this work, the internal line breaks in the explanatory text had
to be removed to make the text flow properly with an arbitrarily-sized
tooltip.
EGL_WL_bind_wayland_display definitions are needed only in one cpp file,
so move them there instead.
We need to duplicate EGL_WL_bind_wayland_display definitions because
libepoxy doesn't define them for us.
At the moment, the render backend provides its specific implementation
of LinuxDmaBufV1ClientBuffer. This has some of its limitations. For
example, due to the strong coupling, compositing restarts must be
handled carefully. It's hard to have a generic code path to import
dmabufs, which would be nice to have in order to unify graphics buffer
allocation across various backends; currently, it's all scattered.
To make the code simpler, this change drops the commented out YUV import
code path for now. Given that Mesa implicitly handles it, the need for
it is no longer so urgent.
ending a drag will update focus. Kwin explicitly resets it to whatever
is now under the mouse now that the implicit grab has ended.
This means no-one sends a pointer up.
Clients (xwayland) don't automatically make leave events count as a
mouse up, because typically you don't get a leave event whilst we have a
grab.
Xwayland also can't track the status of the wl_datasource as it didn't
use it.
This patch shouldn't affect any wayland clients as we don't send a frame event
until the focus changes which is after the dnd_finished events.
BUG: 465444
Testing done:
- dragged firefox under xwayland tabs out from firefox to the desktop
- confirmed a new window appeared
When showing the window RHI will realise the window has no underlying
platform window and create a temporary offscreen surface, different from
the offscreen surface we'll eventually be rendering into. This will use
the format of the main window.
If this offscreen surface format does not match the format of the
context we can fail in makeCurrent calls.
l10n daemon script