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.
TestWaylandSeat::sync() ensures that events and requests can't be
reordered after it. That is, it guarantees that
- events sent from the compositor will be processed by the client
before sync() finishes
- requests issued by the client will be processed by the compositor
before sync() finishes
WaylandSyncPoint relies on the fact that wl_display_sync()'s callback
and other wayland events will be processed in the same event queue.
But, it's not the case right now. The wl_callback belongs to the default
event queue and KWayland::Client::Seat belongs to a different queue.
If the default event queue is dispatched first, the WaylandSyncPoint may
emit the done signal too early.
In order to fix sync(), this change ensures that WaylandSyncPoint's
wl_callback uses the correct event queue.
The test fails because it incorrectly handles the server-side and the
client-side virtual desktops being removed within one event loop cycle.
In order to fix the test, this change makes the removal of server-side
virtual desktop object take effect immediately.
Currently the test spends a lot of time idling. This change speeds up
the test by removing QTest::qWait() calls.
The sync() helper was introduced to sync both client and server sides.
It lets us simplify some code and get rid of QTest::qWait()s.
With this change, the execution time will drop from 20s to about 300ms.
The main motivation is to avoid scattering graphics buffer things around
kwin.
DmaBufParams struct has been moved to the OutputBackend, but with the
introduction of buffer allocators, we need to port screencasting code to
the new abstractions some time in the future.
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.
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.
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.
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
As a first step to move away from having an external service remember output settings
for KWin, this commit introduces an output manager that can load configuration files
and generate new output configurations.
QtConcurrent::run()'s return type is marked with [[nodiscard]], which is
not nice to code that just needs to move some tasks to a worker thread.
On the other hand, QThreadPool satisfies our needs too and Qt doesn't
need to construct futures that we won't use.
One remark about the screenshot plugin: the task lambda is mutable so it
cannot be represented using a std::function.
Destroying a zwp_text_input_v3 object should be viewed as disabling it.
isEnabled property is cached because it cannot be computed in
_destroy_resource() handler. By that time, the resource no longer will
be in resourceMap(), so TextInputV3InterfacePrivate::isEnabled() will
erroneously return false even though we expect true.
If a client owns several windows (for example it can be the case with
plasmashell) and it crashes, it's possible to encounter the following
case:
- xdg_wm_base resources are destroyed
- xdg_toplevel is destroyed
- another xdg_toplevel is destroyed
When kwin processes the destruction of the first xdg_toplevel, it may
ping the second xdg_toplevel. But the xdg_wm_base is already free()d by
that time, so kwin can access already released memory.
In order to prevent that, make the associated XdgSurfaceInterface
objects inert. Since XdgToplevelInterface and XdgPopupInterface will
become useless after destroying XdgSurfaceInterface, make them inert too.
As the spec states, it's illegal to destroy a bound xdg_wm_base object
while there are still alive xdg surfaces created by it so destroying the
surface role objects should be fine.
Wayland has a limited size for strings in arguments. We should truncate
any strings that come from user-defined data before sending.
We keep the full title around within kwin as it keeps logic simpler.
Size length logic is lifted from QWaylandWindow's setTitle
BUG: 465775
Even though zwp_text_input_v2_content_hint and
QtWaylandServer::zwp_text_input_v2::content_hint represent the same
values, they are not the same from the compiler perspective.
Otherwise we confused clients in the following situation:
Client A sets selection, but due to timing has lost focus
User copies something in client B
Client later tries to paste in client A.
Client A still thinks it owns the selection so does nothing.
CCBUG: 459389
Buggy clients can commit the wl_surface several times in a row. On the
other hand, XdgToplevelInterface and XdgPopupInterface consider a
surface to be initialized if it has been configured. If the second
wl_surface commit comes before the configure event is sent, kwin will
initialize a toplevel or popup twice, which can trigger asserts.
BUG: 466530
Converting to wl_fixed is lossy. Especially for non-round values like 1.15.
This causes various visual glitches and off sizes.
Given we're using units of 120ths for the fractional scale protocol it makes sense
to fix the passed values for anything else over the wayland protocol.
BUG: 465850
Testing done:
ran a 1920 screen at 1.15 scale, got a logical size of 1670 which matches what it should be
PointerInterface is a "Server-managed multicasting resource". As in we
have one QObject, managed by the server, but internally it represents
multiple resources from various clients.
We cannot control the lifespan of those resources, they may persist long
after we stop having these capabilities on the seat.
If we delete our pointer object when we stop advertising a pointer
capability we have race conditions with clients calling release, or
potentially even having a seat_get_pointer in flight.
It's easier and safer just to have PointerInterface last as long as the
Seat. If we don't have a mouse no-one should try to bind, and even if
they did or remained bound long after we stop having a mouse it won't do
any harm as there are no mouse events to broadcast.
Normal event flow is from a client view is
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
or
wlr_data_control_source.cancelled
wlr_data_control_device.selection
However when the race mentioned in the comment happens the client
sees
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
wlr_data_control_source_cancelled
Which can confuse client state thinking the clipboard didn't change
as it associates the selection event with its own request. Resend
the selection event in this case to tell the client the correct
selection.
BUG:464509
FIXED-IN:5.27
Sending an axis event for every high-res scroll wheel movement was
causing excessive scrolling on clients that expect low-res (discrete)
scroll events.
Signed-off-by: John Brooks <john@fastquake.com>
Main reason to support this old interface is because this is the only
protocol chromium (and effectively all electron app) that supports.
The protocol itself very similar to text-input-v2 with some minor difference.
So not hard to support by just duplicate some existing code. There might be
some unclear protocol design issue if kwin need to support multiple SeatInterface,
but for now it should be ok to assume there is only one seat.
Tested using fcitx5 against weston-editor and chromium with flag
--enable-features=UseOzonePlatform --ozone-platform=wayland
--enable-wayland-ime
We need to monitor whether the inhibitorActive signal gets emitted. It
reduces the test's execution time from about 5 seconds to a couple
milliseconds.
