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>
We haven't actually seen any reports that it's necessary on any screen, and it causes some weird
and broken screens to misbehave.
BUG: 495242
(cherry picked from commit 00f10569b3)
There are cases where the minimum luminance can be lower than the transfer function's minimum; in those
cases, the transfer function's minimum would get mapped to a value greater than black in the target
transfer function. To avoid that, this just takes the max. of the metadata and transfer function minimum
BUG: 494854
(cherry picked from commit cef6656ff5)
xcb_connectxx() always returns a non-NULL pointer to a
xcb_connection_t, even on failure.
(cherry picked from commit c5185611a5)
Co-authored-by: Xiao YaoBing <xiaoyaobing@uniontech.com>
If a window is already being moved, just switch the current virtual
desktop rather than update Workspace::moveResizeWindow() which is going
to trip an assert.
(cherry picked from commit b97c0f07a3)
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Software brightness is very useful when the backlight really can't be controlled by us, but if it's just temporarily
unavailable because of powerdevil not running, or DDC/CI having issues, then it's best if we don't darken the image
in software on top of the backlight level still being set by the display.
(cherry picked from commit 4f18aae673)
This ensures that we don't fail to enable normal screens when the non-desktop ones can't be
enabled.
BUG: 493148
(cherry picked from commit 741bdb0b6b)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
This is needed for proper crash reporting with full metadata
(cherry picked from commit 5c2153f5ef)
Co-authored-by: Nicolas Fella <nicolas.fella@gmx.de>
Once tearing is enabled, atomic tests that try to disable the cursor plane will fail.
BUG: 493166
(cherry picked from commit 21b1132695)
Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>
l10n daemon script
Xaver Hugl
Vlad Zahorodnii
Kai Uwe Broulik
Jonathan Riddell
Alessandro Astone
Niccolò Venerandi
Nicolas Fella