With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
QSize() will construct an invalid size. An invalid size has width and
height set to -1. In other words, QSize() != QSize(0, 0). This can create
issues when computing the bounding rect of a surface that has invisible
subsurfaces.
For example, if the subsurface rect is QRect(0,0 -1x-1), the top-left
corner of the bounding rect will be affected.
In order to make computation of the bounding rect robust, initialize the
surface size to 0 explicitly.
BUG: 454535
QRectF::contains includes all edges. If two subsurfaces are next to each
other ::contains will treat it as having a singularity where a value is
on 2 subsurfaces rather than either one of the other, which isn't what
we want for our purposes.
The unit test is extended but also featured some wrong values, the
biggest clue that it was wrong was that we used different test
co-ordiantes for surfaceContains and inputContains.
Anything in xcb_ structs are always in X local, all member variables
aside from buffers are in kwin local space.
This patch ignores a few paths that are not relevant on wayland.
This allows for compositor managed different co-ordinate space between kwin's
logical co-ordinate space and a client's logical co-ordinate space.
When combined with a modified kwin!1959 this allows us to set a DPI in xrdb and
mark all xwayland windows as being 2x (or other) and avoid upscales for xwayland
clients in a way that doesn't impact other wayland clients or require
third-party changes. Any use of fractional values is in layers we control
instead of over the wire. kwayland-server is the right place for this
abstraction as we need Outputs to differ on a per resource basis. Something we
can't control from within kwin.
Right now only protocols used by Xwayland are covered. If we covered
remaining protocols we can offer user-control on all remaining clients which
could open up other possibilities such as a user controlled dynamic resizing,
or adapt to possible future protocol changes with wayland scaling.
If the source rectangle is not set, we need to use the surface size
given by the attached buffer. It's computed as buffer size / scale, but
the buffer can also be transformed. In other words, we need to compute
the natural surface size as follows - buffer size / scale and transpose
the result if the buffer is rotated 90 or 270 degrees.
dmabuf-feedback allows the compositor to give the client feedback on what
formats and modifiers are best to use, and for which devices it needs to
allocate its buffers, which improves performance and efficiency.
A dataDevice has a request to start a drag with multiple parameters.
As kwayland's goal is to turn an event-driven API into a property cache API we
store this data. This patch moves that storage to the Seat as properties of the
active drag, rather than a property of the data device that happened to
initialise it.
This both helps keep a lot of other logic together, but also allows us to expose
a public startDrag method that can be invoked from Kwin's internal surfaces or
xwayland.
Any properties in DataDevice now relate to data being dropped on the device.
wl_callback and wl_region are two kinds of objects that are frequently
allocated.
Currently, we make two extra heap allocations per each wl_callback
object. One for the wrapper object (FrameCallback) and the other one is
for its Resource.
With this change, no extra allocations will be made. Also, due to
relying on wl_resource linked lists, the destroy listener implementation
got much simpler.
This won't result in huge memory usage or performance improvements, but
still it's worth reducing the number of memory allocations where possible.
Currently, we store all surfaces in a single list and use linear search
to find the SurfaceInterface by its object id and client connection.
With this, we first search for the wl_resource object by its id. Once we
have a wl_resource, SurfaceInterface::get(wl_resource) can be used.
The main advantage of the proposed solution is that we don't need to
maintain a static list with all SurfaceInterface objects.
A subsurface should be considered mapped only if it has a buffer
attached and its parent is also mapped.
Currently, mapped status logic in SurfaceInterface is somewhat broken
for sub-surfaces. For example, the mapped() signal will be emitted even
if the sub-surface should be considered unmapped according to the spec.
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.
Currently, the swapStates() function does two things - (a) it merges one
state with another; (b) it applies the next state. This change splits the
swapStates() so it's simpler and the boolean trap can be removed.
Currently, the committed signal is emitted after the client has called
wl_surface.commit. However, this breaks with synchronized subsurfaces.
Notably, Firefox splits a web page in a bunch of smaller layers, which
can be backed by wl_subsurface objects.
All the subsurfaces are in the sync mode. If a layer needs to be
repainted, Firefox will commit the corresponding subsurface with a frame
callback.
Since the committed signal is emitted when the wl_surface.commit request
is invoked, kwin will schedule a new frame immediately. Meaning, that it
is quite likely that firefox will have old contents.
The right thing to do would be to schedule a frame when all the ancestors
of the layer subsurface have been committed.
This change re-jitters the commit logic so the committed signal is
emitted when a new state is applied to the surface. It also slightly
cleans up how SubSurfaceInterface::parentCommit() is called.
It will be nice to cleanup the commit logic further by calling the
surface role's commit hook unconditionally, i.e. not check whether it's
a subsurface. But doing so may result in infinite recursions. How to
clean up that is still TBD.
According to the spec, if the parent surface is specified in the
wl_subsurface.place_below(), the subsurface has to be rendered below the
parent surface.
At the moment, kwaylandserver doesn't handle that case properly. It is
not possible for sub-surfaces to go below the parent surface.
Another issue is that we wrongly assume that the place_above request
will put the subsurface on top of the stack if the parent surface is
specified as sibling. It doesn't seem like that's the case, not
according to the spec.
This change splits the child sub-surface list in two lists - below and
above. The alternative solution is to store the parent surface in the
children list, but it's an error prone solution and it's conceptually
weird.
This way, it's less characters to type. In order to support delayed
surface commits, compositor extensions need to piggyback their state on
the state of the wl_surface. In other words, SurfaceState is going to
be used not only by SurfaceInterface, but the viewporter extension, the
xdg-shell extension, etc.
The following order of events are legal:
Typically order is:
- server announces a new output
- client binds to a new output
- server updates the surface to be on new output
But we can have events occur in the following order:
- server announces a new output
- server updates the surface to be on new output
- client binds to a new output
At which point when we update the surface there is no ID to tell the
client which output the surface is on.
This patch watches for clients binding to output and updates
appropriately.
This change rewrites implementation of subsurfaces with qtwaylandscanner
and fixes various smaller issues, such as proper handling of position
updates for subsurfaces in the desync mode and getting rid of QPointer in
the public API.
Some input related code in kwin is mislead by the fact that when the
input region is infinite, SurfaceInterface::input() is going to return
an empty QRegion object.
We cannot really do that because the client could have just set a valid
empty wl_region object to ignore all input events.
This change makes SurfaceInterface assign an actually infinite region
when a NULL input region has been passed to set_input_region().
Order of a client teardown is:
- ClientConnection is removed from the static map
- All our client owned resources are torn down
- ClientConnection is deleted (via a previous deleteLater)
The recent refactor led to a behavioural change where ::client could
return a null pointer.
We want the client getter to be valid throughout the lifespan of
SurfaceInterface, by doing the lookup once we achieve that.
BUG: 424255
The main purpose behind the kwaylandserver library is to provide a set
of re-usable wayland compositor extension implementations. However, it's
worth noting that the design of kwaylandserver is far from perfect at
the moment.
KWaylandServer tries to hide all low level wayland details from the
compositor. But it's not the case with buffers, which diminishes the
whole point behind the library.
Creating OpenGL textures from Wayland buffers is the responsibility of
the compositor. So, when it comes to client buffers, we are one foot in
KWaylandServer, and the other foot in the compositor.
Since the surface size is a logical size, the compositor can't use it
for allocating memory for OpenGL textures. This change adds the buffer
size property in SurfaceInterface that can be used for allocating memory
for textures as well as monitoring buffer size changes.
I must say that the introduction of the buffer size property is a crude
hack because BufferInterface just needs to provide an OpenGL texture for
each plane. The main blocker for that is that it would involve moving
the backend, the compositor, and the wayland bits in the same place, for
example kwayland-server or ultimately kwin.
The buffer scale and the buffer transform property specify transforms
that had been applied to the buffer's contents. Neither one of those
properties apply to the surface, in other words the buffer transform
property doesn't indicate that the surface was rotated or flipped or both.
This change doesn't gain anything in terms of new features, etc. It just
attempts to make things more clear.
The compositor needs to monitor changes in the mapping between the
surface local coordinates and the buffer coordinates because texture
coordinates correspond to the latter. One way to do it is to monitor
things such as the surface size, the buffer size, the buffer scale,
etc. The main problem with doing so is that there are so many factors
that contribute to how mapping between the surface local coordinate
space and the buffer coordinate space is performed.
In order to provide a generic way for monitoring changes in the mapping
between the surface local coordinate space and the buffer coordinate
space, this patch introduces two new matrices. The first one specifies
how the surface-local coordinates are mapped to buffer coordinates, and
the other one specifies how to map the buffer coordinates to surface
local coordinates.
With the new two matrices, the compositor has a generic way to get
notified when it has to re-compute texture coordinates.
The wp_viewporter compositor extension allows clients to crop and scale
their surface. It can be useful for applications such as video players
because it may potentially reduce their power usage.
Unfortunately, in order to map a point from the surface-local coordinate
space to the buffer pixel coordinate space, one cannot divide the point
by the scale factor since the buffer might be rotated or flipped.
This change introduces a couple of helper methods for converting points,
regions, and rectangles from the surface-local coordinates to the buffer
pixel coordinates and vice versa.
Summary:
So far all double-buffered properties in our implementation of xdg-shell
weren't actually double-buffered. When a property setter is invoked, we
pray to the God hoping that the client committed associated surface.
This change introduces private SurfaceRole class. The new class provides
a way for SurfaceInterface to commit pending state of associated shell
surface.
The chosen architecture allows us to do more in the future. For example,
we could use SurfaceRole to prevent associating several roles to a single
wl_surface object, e.g. xdg-toplevel to a pointer surface, etc.
Test Plan: This change breaks support for client-side decorated clients in KWin.
Reviewers: #kwin
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23745
Summary:
Missing from our surface handling was the damage_buffer call introduced in
version 4 of the wl_compositor interface.
Its only difference to a normal damage call is that the damaged region is
supposed to be defined by the client in buffer coordinates instead of
surface coordinates. This damage must be tracked separately in KWayland
and on commit with the buffer transformation united with the normal damage.
Test Plan: Autotest updated.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15910
Summary:
Allows a compositor to set a proxy surface to handle drag and drop
operations place of the actual surface the drag originated from.
One proxy surface can handle multiple origin surfaces at the same time. These
need to get registered once. The active remote surface gets set when a pointer
button is pressed on the surface.
Test Plan: Manually with KWin's Xwayland DnD patches.
Reviewers: #kwin
Subscribers: davidedmundson, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15421
Summary:
This protocol allows to indicate that a wl_surface should inhibit idle
actions such as DPMS, screen locking if the surface is visible.
The protocol is quite simple: it just creates an IdleInhibitor for a
Surface. If such an IdleInhibitor exists the Surface is considered to
inhibit idle.
On the server side it is also exposed like that through the API. The
IdleInhibitorInterface is private to the library and only
SurfaceInterface is extended to expose whether it currently inhibits
idle.
CCBUG: 385956
Test Plan: New test case added
Reviewers: #frameworks, #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D8396
Summary:
As per existing TODO.
A new signal is added on Global to emit so we can process the result
whist we still have a valid object. The name is overly explicit to try
and logically separate it from QObject::destroyed().
Test Plan: Updated existing unit test.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, anthonyfieroni, plasma-devel, #frameworks
Tags: #frameworks, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D7531
Summary:
The pointer constraints protocol is an unstable protocol and thus
the implementation follows the semantics of unstable protocols.
The protocol allows to create a constraint on the pointer - either a
lock or a confinement on a surface. Those are not activated at once, but
when the compositor actively grants it.
During lock no further pointer motion is emitted, during confinement the
pointer is kept in a certain area.
This implements T4451.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3466
