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
Makes it so the GlobalShortucts object gets built and its KGlobalAccelD
parts get disabled.
Addresses the TODO in GestureHandler.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If a SwipeGesture or a PinchGesture is cancelled, the associated QAction
is going to be triggered. It is against the expectations of the gesture
handlers.
In order to address that, this ports the gesture handlers to the native
gesture apis, which expose whether the gesture has been started or cancelled
better.
After !5532 a new code path was triggered during Workspace::rearrange call.
When first Polonium window opens on any screen, there is no active tile yet.
This forces geometry calculation in Window::checkWorkspacePosition -> Window::ensureSpecialStateGeometry
To return empty QRect, which depending on the screen arrangement will move window to the other screen.
This confuses Polonium plugin, as it receives wrong outputChanged signal in scripting API.
BUG: 488898
Signed-off-by: Alik Aslanyan <inline0@pm.me>
The currently used cursor theme can be different from the configured one.
For example, if the configured theme cannot be used.
In order to ensure that that case is handled well, this change makes the
shake cursor plugin uses the same cursor theme as PointerInputRedirection.
At the moment, the shake cursor respects the current cursor shape. But
there are couple of drawbacks behind doing it: the first is that it's
very likely that the cursor pixmap has low resolution, the second is
the cursor can be hidden client-side.
This change makes the shake cursor plugin load the Xcursor theme with
a high enough size and display the default cursor shape regardless of
what the client has set in order to address the two aforementioned issues.
At the moment, the FocusChain has Q_ASSERT()s to prevent inserting closed
windows back into the focus chain. It makes sense on paper. But, there
are code paths that could still hypothetically call FocusChain::update(),
they are harmless except the logic in the FocusChain.
So instead this change makes the FocusChain ignore closed windows, i.e.
take a more defensive approach. There are a few reasons why it's
worthwhile doing: the first is that it would prevent inserting closed
windows back into the focus chain in release builds and potentially even
back into the stack, debugging such crashes is absolutely no fun; the
second is that it would be preferred to avoid sprinkling random
isDeleted() checks in the Window code here and there and thus making
the code harder to follow.
Vlad Zahorodnii
Aleix Pol Gonzalez
l10n daemon script
Xaver Hugl
David Edmundson
Andrew Shark
Jonathan Riddell
Akseli Lahtinen
Alik Aslanyan