The behavior between direct scanout and normal presentation being different is an
implementation detail of DrmPipeline, the output layers shouldn't need to care
Multi monitor setups with 4K screens are not uncommon and one of the
annoyances associated with such setups is that you lose the track
of the cursor sometimes. It's natural to shake the cursor in such
occasions.
This change enables the shake cursor effect to improve the desktop
experience. One potential risk associated with doing so is that the cursor
can be magnified in some undesired situations. It is true. But we took a
great precaution of that and added some heuristics to avoid triggering the
effect in such cases given all the data we have available.
Only store one history item for movement in the same direction.
With this optimization I measure m_history.size() <= 15 for all kinds of
movements, including back and forth, and circular.
The current behavior is that the cursor size follows how hard or fast
the cursor is shaken. While this looks fancy, given the purpose of this
plugin, it should be possible to magnify the cursor as easy as possible
without interfering or false triggering.
This change implements a sort of a compromise. When the cursor is shaken
for the first time, the cursor is magnified by some certain scale factor.
Then every next shake magnifies the cursor further by a smaller amount.
When using fractional scaling, an xwayland window's client geometry can
have some fractional part. When that's the case, .toRect() can shrink the
client geometry or extruding the decoration borders inside the surface.
On the other hand, the pointer is going to be confined as long as the
wl_surface is focused. If the focus jumps to the decoration, the pointer
constraint is going to be broken. Unfortunately, the focus can shift to
the decoration even though the wl_surface is still focused because of the
pesky .toRect().
BUG: 482448
CCBUG: 477124
When GPUs are barely loaded, render times can spike randomly, likely because it goes
to a lower power state and has to ramp up again when KWin renders. To ensure this
doesn't make KWin drop frames, assume rendering always takes at least 2 milliseconds
Due to some misinterpretation of mode timings, the old method calculated vsync, not vblank,
so the resulting duration was much shorter, which caused frame drops on some systems.
BUG: 482064
When a key is pressed the string that should be used in the key event
changes depending on the xkb updated state for composed keys.
The key itself should be not be affected.
In the codepath to keep xwayland notified of key presses we have to
check the focussed window is not already an xwayland client. To avoid a
null dereference a guard is added that the focussed window is not null,
however the current code incorrectly returns early intead of skipping
just the relevant check.
BUG: 478705
```
/var/tmp/portage/kde-plasma/kwin-6.0.49.9999/work/kwin-6.0.49.9999/src/input_event.h:21:7: error: type ‘struct MouseEvent’ violates the C++ One Definition Rule [-Werror=odr]
21 | class MouseEvent : public QMouseEvent
| ^
/var/tmp/portage/kde-plasma/kwin-6.0.49.9999/work/kwin-6.0.49.9999/src/plugins/mouseclick/mouseclick.h:27:7: note: a type with different bases is defined in another translation unit
27 | class MouseEvent
| ^
lto1: some warnings being treated as errors
```
Bug: https://bugs.gentoo.org/921558
Signed-off-by: Sam James <sam@gentoo.org>
This is to help to fix maximized xwayland windows not covering the whole
work area. Size hints are obeyed only when restoring the window.
According to the net wm spec, the window manager should not obey size
hints when maximizing a window and some other window managers already ignore
them when maximizing windows.
CCBUG: 459373
Currently desktop grid view is missing the selection rectangle when hovered over a desktop.
This adds the selection rectangle on hover, since it used to be there before three-state design.
Currently selected desktop has thinner and different colored border.
BUG:481812
The end render timestamp can be slightly in the past before the start
render timestamp. This results in negative render times, which can make
kwin wait way more than just one vblank interval before starting the
next frame.
It appears that there is no way to detect if the gpu has performed a
disjoint operation in OpenGL. It's available only in GLES. As a way
around, this change makes the GLRenderTimeQuery insert two probes: one
queries gl timestamps when starting rendering and ending rendering;
another one just queries std::steady_clock before and after painting.
This hardens the GLRenderTimeQuery against OpenGL providing nonsensical
results sometimes.
BUG: 481721
We know that org.kde.breeze.desktop is invalid as LayoutName for the
tabbox, it will break the default button in the tabbox kcm.
Also the DesktopListLayout and DesktopLayout aren't valid anymore
BUG:481640
Now that we have Wayland around, there's a whole branch of dependencies
that shouldn't be necessary anymore.
This allows to build KWin without all of it, allowing us to have a much
more compact alignment for cases where all the legacy software isn't
necessary anymore.
Bundle KWindowSystem X11-specific headers into it too, since it's part
of the same process.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
