`stacking` can be empty, in which case, QList::first() must not be called.
(cherry picked from commit a9de526787)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This fixes client-side decorated windows such as chromium displaying
"black bars" when they are being interactively resized.
The idea behind the fix: send a sync request and block wl_surface commits
to freeze the surface, wait until the client repaints the window and acks
the sync request, unblock wl_surface commits (in response, Xwayland will
commit a new buffer), repeat the cycle if the pointer is moved again.
(cherry picked from commit 23f854405f)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
`m_commits.front()` is a reference to the first item in the m_commits
list. If it's submitted sucessfully, everything will be alright.
If the candidate commit fails, it can be merged with other pending
commits in the m_commits list. It will also invalidate any previously
taken reference to the first item in the m_commits list, which is not
okay for commit->test().
(cherry picked from commit 4f4f35e01a)
SurfaceInterface implementation details have changed. On the other hand,
it would be great to avoid queued connections because they make code less
predictable.
(cherry picked from commit 06fba221d4)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
The previous code emulated "pass through" behavior by adjusting the reference luminance to
the preferred color description's reference luminance, but that doesn't work out in all
situations, like when the preferred color description changes but the client doesn't commit
any color management changes on its surface.
This approach fixes that by just adding a boolean flag for this pass through mode to the
color description, and setting it in the protocol implementation.
This commit is 6.2-only, as the master branch has dropped this pass through emulation and
doesn't need such hacks for HDR content to behave properly on settings changes.
BUG: 494134
Apparently some HDR screens only show the minimum luminance if you send them a value of zero,
instead of the minimum luminance they report in the EDID. To work around that, assume the
minimum value of the transfer function instead of what the screen reports as the minimum.
BUG: 494128
(cherry picked from commit c8849b83c1)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Normally, pointer values are in logical units, which get implicitly scaled with the scale of
the screen, so scaling them when scaling Xwayland makes sense. If the pointer moves too fast
for the user with that scaling, they will simply use the libinput pointer acceleration setting
to reduce that speed in a manner that's uniform for all their screens.
However, unaccelerated values are not affected by that setting, and thus they should also not
be affected by the screen's scale. This commit removes that scaling for Xwayland, which matches
SDL's usage of the value in Wayland native mode and brings it in line with user expectations.
BUG: 483067
(cherry picked from commit 47f800c127)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Amends 6738473f3d.
It's better to check whether Item::childItems() has the same items as
Item::sortedChildItems() first because it gives more context about the
integrity of the lists.
If Item::sortedChildItems() is corrupted but Item::childItems() is fine,
we may miss that important detail because
"aliveWindowItems != sortedWindowItems" comes first.
(cherry picked from commit 1df73874fc)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Otherwise, the following situation can happen
- effect tries to schedule a repaint, which gets ignored because the window has at least 30fps
- the window stops updating
- the effect's last frame is stuck on the screen, until something else triggers a repaint
BUG: 493940
(cherry picked from commit 371879a9f9)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
The added test ensures that setQuickTileMode doesn't misbehave when a window rule
forcing the window in question to be maximized is in place
(cherry picked from commit d351c4c554)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
It seems that QMenu expects to receive keyboard focus when it's mapped,
otherwise keyboard input breaks when using pointer input. In either case,
kwin should move keyboard focus immediately rather than do it on demand.
BUG: 465385
(cherry picked from commit 19c467147a)
The issue was fixed upstream. Technically, it also introduces a new
behavior: super keys are interpreted as meta keys now by default. It
matches what qtwayland does and, in general, Qt controls handle super
keys very poorly. Wayland clients still receive native scan codes,
they are not affected by these changes.
(cherry picked from commit 805414c071)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
By default, events are accepted, we want the opposite.
(cherry picked from commit 4711fe1961)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
If there's a window rule, setMaximize may not actually change the maximize mode, so this
needs to be accounted for
BUG: 493778
(cherry picked from commit 68015321e9)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
We need to use the requested modes, instead of the current ones, otherwise the data can be
outdated because it requires the client to react to what KWin requested first.
This fixes the placement tracker sometimes not restoring quick tiled windows when the quick
tiled state changed during the last placement tracker restore.
Fix "Toggle raise and lower" functionality for a case when there are
windows in higher layers present on the same desktop; a window that is
being acted upon could never be top-most in such a case, which prevented
it from being lowered by "Toggle raise and lower" action.
Checking if a window is top-most now uses unconstrained_stacking_order
list, which reflects user-requested stacking window order, but doesn't
know anything about layers, and that in turn allows any window that user
has raised most recently to be lowered by "Toggle raise and lower" (even
if this window is not actually top-most, because of windows in higher
layers).
BUG: 440540
(cherry picked from commit dad57ad0a0)
Edge::window()/Edge::approachWindow() is an X11 implementation detail.
(cherry picked from commit 9d419ea5fe)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Workspace::adjustWindowPosition() properly handles hidden windows and it
also excludes more window types, but Workspace::adjustWindowSize() only
shares a small fraction of those checks due to getting out of sync because
of code duplication.
BUG: 461987
(cherry picked from commit 260319c30f)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Currently, when a cancel() is called for a cross-fade animation, the
window will not be unredirected.
BUG: 488893
CCBUG: 486023
(cherry picked from commit c4116173aa)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Some hooks need to run on X11 startup.
On X11 this is handled by the login manager, for XWayland this is the
responsibility of the desktop.
Long term, we want Plasma to make XWayland actually on demand and therefore we
should use the initfd for these startup scripts before the application connects.
BUG: 493054
(cherry picked from commit ce8927c938)
Co-authored-by: David Edmundson <kde@davidedmundson.co.uk>
While the xdg shell specification says otherwise, in practice we have apps that
are translucent and expect that to work in fullscreen. More importantly, if we
don't enforce opaqueness with GPU compositing, we shouldn't do it in scanout either
BUG: 493222
(cherry picked from commit 274ef5c973)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Input redirection doesn't have the pointer buttons on X11, so it can't be relied on
there
(cherry picked from commit a217484be7)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
A closed window cannot react to new geometry, also requesting new
geometry can involve accessing resources that are gone/deleted now.
Scripts trying to move or resize a closed window is a bug though.
BUG: 492213
(cherry picked from commit f339c4281f)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This rule is still useful for Xwayland windows, for Wayland native
windows it is indeed useless, the ui can be polished later, if needed.
(cherry picked from commit e197540c2b)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Amends e482556d58.
The client() check was accidentally lost in the linked commit.
BUG: 474873
(cherry picked from commit f9ff283f95)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This ensures that the window is always alive as long as the sheet
effect animates it.
(cherry picked from commit bd9c81c6cd)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
There might be more XdndStatus client messages after a drop occurs. In
which case avoid sending XdndDrop client message again as it can result
in a feedback loop with clients such as GIMP.
BUG: 482298
(cherry picked from commit 48faf8314d)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This is not automatically pulled in on Musl and without it dev_t is
undefined
(cherry picked from commit 77508939e6)
Co-authored-by: Bart Ribbers <bribbers@disroot.org>
Vlad Zahorodnii
l10n daemon script
Nicolas Fella
Jonathan Riddell
Xaver Hugl
Jarek Janik
David Edmundson