This avoids doing multiple atomic tests with outdated state for when multiple
outputs change simultaneously, and avoids crashing because outputs get used
before they're fully constructed
(https://crash-reports.kde.org/organizations/kde/issues/40960)
Qt applications use Static window gravity by default. This means that if
a window decoration is created, the client window should remain at the same
position in the global coordinate space. To do that, X11Window needs to
move the frame geometry by (-borderLeft(), -borderTop()).
On the other hand, after making X11Window::framePosToClientPos() round
the window borders, the client window can end up being moved more than
expected when applying the gravity adjustment.
This change makes X11Window also round the gravity adjustment so the math
is consistent there and in the framePosToClientPos() function.
BUG: 489016
don't blindly access m_tileManagers as it can assert
with out of bounds when output is not valid. This can happen
from scripting side as this function is wrapped in the javascript api.
Adds whitespace between documented members of the header file.
Currently the members are all bunched together, making it difficult to
read as one flows directly into the next. This change adds a newline
between each member, making it easier to read.
The internal effects implement some of the core plasma functionality, for
example screenshots, but being an effect is rather an implementation detail.
Also we have pivoted towards unloading the desktop effects kcm and moving
effect configuration in more appropriate places.
BUG: 488988
This ensures that different content on the screen matches with the user configured
reference / SDR luminance, and both simplifies SDR<->HDR mapping by removing the need
for special casing that situation and significantly improves the mapping in some cases.
As we don't get any reference luminance values for HDR content (yet), this commit
assumes that HDR content is prepared for the reference luminance of the preferred
color description.
Brightness is a loose word for how bright we perceive things to be, but the
values we're using are about objective measurements, about luminance instead.
If a context is forward compatible, that means the deprecated functions are not
available, and if the QSurfaceFormat::DeprecatedFunctions option is set, that means
they are available.
Wrongly setting QSurfaceFormat::DeprecatedFunctions thus causes Qt to use OpenGL in
a way the context doesn't actually support.
CCBUG: 486460
If two mouse areas are stacked on top of each other and a button press
event is sent so one of them accepts it, QMouseEvent::isAccepted() will
still return false. It's a QtQuick bug, see the associated upstream bug
report https://bugreports.qt.io/browse/QTBUG-126733.
On the other hand, given that the MenuButton implements its own input
handling, we can port it away from DecorationButton to mitigate the issue.
BUG: 488993
The preedit struct holds values that need to be effectively double
buffered till the preedit string is set. There is no need to store the
text in this struct as it is reset at the end of setPreeditString
It's usefulness is doubtful, the current visuals poorly map to the
wayland abstractions, and it's partially incomplete because surface
previews are only shown for surfaces that have wl_shm buffers attached.
Tree hierarchy changes are also handled very poorly.
There are a couple of reasons why it's worthwhile doing:
The first is that it makes the logic in the updateServerGeometry()
function reusable for the interactive code path. As of now, when the
window is being interactively resized, doInteractiveResizeSync() will
issue some xcb_configure_window() calls but then it also implicitly
assumes that updateServerGeometry() will call updateShape() and
updateInputWindow() but skip m_frame.setGeometry() later. That is
confusing, and error prone. For example, if somebody drops
m_lastFrameGeometry in favor of m_frame.geometry() (which is an
absolutely reasonable thing to do btw!!), a regression will be
introduced: things would appear to work at first, but then eventually
bug reports about input working weirdly would start piling up.
The second is hidpi scaling of wayland clients. toXNative(a + b + c)
is not the same as toXNative(a) + toXNative(b) + toXNative(c). By
switching to the device geometry, we leave less space for making an
error.
The third is that lets us clean up some geometry manipulation code.
When dealing with window hierarchies, it's more convenient to have
m_window.position() rather than a dedicated property in the X11Window
class such as wrapperPos().
If the logical geometry changes, the X11Window still needs to verify
whether the currently applied native geometry differs from it. In order
to do that, the X11Window needs to map the logical geometry to the device
pixels. Given that X11Window already maps the logical pixels to the
device pixels, the Xcb::Window doesn't need to map the geometry again.
Also, the way different coordinate spaces are handled now is inconsistent.
Some things (Xcb::Window) work only with the logical pixels, while other
(e.g. client messages) require the user manually mapping the geometry
between the different coordinate spaces. With this change, it would be
more consistent.
Regarding the porting process, it was performed in a single step because
all the code that changes or reads Xcb::Window geometry is neatly
encapsulated in the X11Window class in a couple of functions.
The mastering display colorimetry describes what part of the colorspace
is actually used, which is important when we're sending desired metadata
about a screen using the rec.2020 container colorspace, or when the client
uses an "infinite" / extended colorspace like scRGB
This is to prevent disconnecting clients that sometimes struggle with
keeping up with the events that the compositor sends. 1 MiB was eyeballed.
Wayland's wire protocol consists of a stream of messages. Every message
consists of a header (2 words: 1 word for object id, the other word
specifies the message size + event/request opcode) and the arguments.
Considering the compositor sending motion events generated by a mouse
with 1000Hz polling rate, we have
- wl_pointer.motion event size: (4 bytes for serial + 4 bytes for x +
4 bytes for y + 8 bytes for header) = 20 bytes
- wl_pointer.frame event size: 8 bytes for header
So in total, if the client freezes for a second, the client buffer size
should be at least (20 + 8) * 1000 / 1024 = 27 KiB. 1 MiB corresponds to
the client not processing the motion events for approximately 30 seconds.
Some old hardware is very limited in the amount of instructions it can support.
In order to not have KWin fail to composite, reject using hardware acceleration
in this case and fall back to llvmpipe or QPainter
BUG: 482868
This helps avoid some frame drops after the GPU may have went into a lower power
state. While this isn't generally noticeable, avoiding this makes noticing and
debugging actually relevant frame drops easier
CCBUG: 488843
