On X11, kwin receives spurious output change events non stop when an
override redirect window is moved around. They stop after restarting
kwin and resume after the output layout changes. It's unclear what the
source of the issue is, but it's likely Xorg.
(cherry picked from commit 31c4fcdfe3)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
This avoids rendering the hardware cursor image each time while tearing is enabled, only to
then throw the result away when updating the plane fails
CCBUG: 495843
(cherry picked from commit b8a16bffa6)
The drm backend doesn't handle changes that do this well, as it requests a pageflip event and the
kernel can't give us a pageflip event for an already-disabled plane.
BUG: 495843
(cherry picked from commit 769c896cdb)
Otherwise, DrmOutput::setDrmDpmsMode will inhibit the renderloop for a second time, and it'll
never be completely un-inhibited, which means the screen stays off.
(cherry picked from commit d90c64bc7c)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
The previous code kept the mode the backend had set as the default, but that's often not the
most ideal one
(cherry picked from commit 89278cdb12)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
This is to disable tone mapping, which makes screenshots of SDR things while HDR is enabled on a
display look a lot worse.
As the tradeoff, this will make HDR content look worse, but that can be fixed later by taking the
actual HDR metadata into account.
BUG: 496185
(cherry picked from commit d62eb36757)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
In https://invent.kde.org/plasma/kwin/-/merge_requests/6747
the comparison with window heap geometry was done with the
heap x/y/width/height properties to detect if the drop was done
off the heap, but this is wrong, because in Overview
window heaps are positioned with Translation transforms, so
we need to properly mapping its geometry with mapToItem
which is transforms aware
(cherry picked from commit 31c4b8ac55)
31c4b8ac effects/overview: Properly map the windowHeap geometry
Co-authored-by: Marco Martin <notmart@gmail.com>
When dropping a thumbnail on another desktop, don't animate the
position, otherwise we see the window oddly flying off the screen
to go on its new position on the different desktop
BUG:495444
(cherry picked from commit 2e0b33eae4)
2e0b33ea effects/overview: Don't make thumbnails fly off the screen
Co-authored-by: Marco Martin <notmart@gmail.com>
Output objects are exposed to scripts, and they have no parent objects,
so QJSEngine can garbage collect them.
(cherry picked from commit a334133376)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
The bug that made me disable it by default was fixed in that version
CCBUG: 488941
(cherry picked from commit cb9d538948)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
This reverts commit 4bc74d6831.
Wine still depends on XSHAPE to implement window clipping APIs in
Windows applications.
BUG: 493934
(cherry picked from commit a12d0723a9)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
scripts could trigger some asserts:
* it was possible to tile unmanaged windows, which caused an assert on
!tile at window teardown, simply forbid it.
* if a window was tiled as soon it appeared, it was possible the window
got destroyed before commitTile was called, causing an assert in
commitTile !isDeleted, in this case only make sure the tile we are
assigning is null
backport from https://invent.kde.org/plasma/kwin/-/merge_requests/6761
We don't use the return value so QList doesn't need to move it around.
(cherry picked from commit 3fbd8fa033)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
If the screen is locked, but the lockscreen isn't ready for painting,
pickFocus() returns the active window. This somehow leads to the
meta key getting "stuck" if you lock the screen with Meta+L.
BUG: 495325
(cherry picked from commit c1e3dc0e08)
Co-authored-by: Adam Nydahl <loginer@loginer.net>
It just wrongly triggers modesets that will then (at least try to) ignore the
leased-away resources anyways, and regress performance on the other displays.
BUG: 495400
(cherry picked from commit f4d24cce43)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
If another window accepts the touch up, that can seriously mess up the touch state and
cause for example the overview effect to misbehave when we have 2 screens.
(cherry picked from commit 4595e41b4e)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
Before, it could break in the following scenario:
- drm backend emits aboutToTurnOff
- workspace creates the dpms filter
- workspace gets some event that triggers it to update outputs
- maybeDestroyDpmsFilter sees that the output is on and deletes the dpms filter
- the drm backend actually turns the screen off
In that case, the dpms input event filter is gone and the output off. Unless the dpms mode
gets changed again by some other process, the output would now stay off forever.
(cherry picked from commit 8676141067)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
The given preferred output can be already removed from the Workspace
when the layer shell window is created. In which case, we should close
the layer shell window.
(cherry picked from commit 002567476d)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
It can change the active output without user interaction
BUG: 495537
(cherry picked from commit 71c9fd7bc0)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
This fixes a porting typo. Previously, the modal was therefore
added twice, once for itself and once for its parent but we actually
do *not* want a window with a modal child at all.
(cherry picked from commit ff052c6d9c)
Co-authored-by: Kai Uwe Broulik <kde@privat.broulik.de>
It's supposed to match the reference luminance; this is just a remnant of KWin using a
different variant of linear internally
BUG: 494930
(cherry picked from commit 3a23b2974a)
If we change the backend the colormap will get leak, the colormap should
be released with xcb_free_colormap before the window destoryed.
Signed-off-by: Chaojiang Luo <luochaojiang@uniontech.com>
(cherry picked from commit 1747518f81)
Co-authored-by: Chaojiang Luo <luochaojiang@uniontech.com>
Since the position of the contentItem depends on the position and scale
of the parent item, make sure to re-evaluate it when the parent changes.
BUG:495501
(cherry picked from commit d7acc24093)
Co-authored-by: Niccolò Venerandi <niccolo@venerandi.com>
Item::scheduleRepaint() invalidates part of an item. It doesn't
invalidate the corresponding part of the scene globally. There are a
couple of reasons why it works the way it is:
- the first, and the main one, is to keep effects like blur working
- the second is to cull out invisible repaints, i.e. repaints scheduled
by obscured items
This kind of repaints is suitable when the size or the position of the
item changes. However, it's not good in case the stacking order changes.
For example, consider two sibling items: `[A, B]`, `B` is on top of
`A`. If the `z` of item `B` is set to `-1`, the effective stacking order
will be `[B, A]`, and only repaints for item `B` will be scheduled. When
`WorkspaceScene::preparePaintSimpleScreen()` processes the next frame, it
will see that item B is occluded by item A, so it will discard item B's
repaints and the corresponding graphics buffer will _not_ be repainted
even though it should be.
In order to prevent that, we need to schedule a global repaint.
Is there a less error prone design? Yes, if we could specify the contents
of every frame declaratively, then we could diff two consecutive frames
without manual meticulous repaint tracking. The magnitude of such changes
is beyond a bugfix though.
(cherry picked from commit cf6f27be06)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
The -wm file descriptor leak prevents the poll() function from returning
POLLHUP when Xwayland dies.
The POLLHUP status will be set when all file descriptors for the other
end point are closed.
BUG: 442846
(cherry picked from commit 40d202976d)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>