When we use a shadow buffer, we always render to the whole surface - setting
the damage region is incorrect and invokes undefined behavior. On the Lima
driver this caused flickering on screen rotation.
To fix this, don't set a damage region when we use a shadow buffer, which is
effectively setting the damage region to the full surface
effects->desktopCoords() returns the position of the desktop in pixels,
while we want the desktop grid coords, i.e. if the virtual desktop is in
the first row, second column, we want m_currentPosition to be (1, 0).
It can happen that the drm backend temporarily lacks permission to do atomic
commits, or that the cached drm property values become out of sync with
the real values held by the kernel. Instead of failing with both, attempt
to update property values and try the commits again at a later time.
Set the time for mouse and touch events. This is especially important
for the mouse is as the timestamp will be used to discriminate between
single and double click. Previously this was always sending the double
click event, making buttons work only every other click.
BUG: 454275
BUG: 449907
focus used to be always forced to the root item of the view in the
"active screen" (which behavior is configurable between mouse poosition
and screen of active window)
now set focus to that particular view only if nothing is focused, also when
the user explicitly sets focus to an item in another view
remove focus to the old one so the item properly focused would be there
BUG:455807
BUG:455783
CCBUG:455633
At the moment, the DrmLeaseOutput class inherits from the
KWaylandServer::DrmLeaseConnectionV1Interface class. While this works,
it's not a future-proof design. For example, kwin could also lease its
"desktop" outputs in order to let another wayland compositor run
alongside it.
Also, it's a good practice to prefer composition over inheritance.
If PlasmaCore.Dialog resizes while visible, the kwin shadow property
used by InternalWindow may update the shadow during rendering and cause
crash related to current context.
After the 5.25 update, one could not see which window was highlighted until one
manually unfocused the SearchField and then pressed any key to refresh the WindowHeap.
Also, the searchbar would (most of the time) "absorb" the arrow keys so one had to
also unfocus it to really be able to select windows with they keyboard.
With this change, there is always one window highlighted while filtering using the
search box. Also, one can select another window with the arrow keys without manually
unfocusing the searchbox. This heavily improves the keyboard functionality in this
effect that got lost with the 5.25 update of presentwindows to windowview and
resolves complaints about the keyboard navigation being buggy.
BUG: 455633
BUG: 455764
BUG: 455099
BUG: 455586
BUG: 455753
FIXED-IN: 5.25.2
In a74c436156, we changed behavior that
every commit() will be followed by a done(), which makes this test might
catch a different done() from server. Change the spy to make sure it
exhaust all other done before checking the one expected.
This makes easier for individual effects to personalize it
without adding ad-hoc api in the main WindowHeap class.
WindowHeap and WindowHEapDelegate are still quite coupled and thing can probably still be improved, but the code should be more readable already
When dpms disabled outputs get set active, they require a modeset. If after
that they are set inactive again without resetting the pipelines first,
they no longer require a modeset but still have the pending properties that
would enable a crtc - but without a framebuffer set.
To prevent this, first test the current setup as it is, and only then see
if the pipelines would work if enabled again.
It makes it very hard to debug any use-case that isn't a strip of
outputs and even then, we should have other mechanisms to arrange
outputs properly (i.e. through kscreen).
At the moment, the effect that animates the screen works as follows:
* render the screen before it's rotated in an offscreen texture
* after screen rotated, paint the offscreen texture in the first half of
the animation but not the screen contents after rotation and in the
second half of the animation, paint the live screen contents
This works but it doesn't take into account things such as blur (I can
see that the region around where the panel should be doesn't look as
expected).
This change makes the screen transform effect do proper cross-fading,
i.e. save the screen before it's rotated in an offscreen texture, render
the current screen in an offscreen texture, and produce the final result
by cross-fading between two offscreen textures in a shader.
Besides fixing the visuals of the effect, another motivation behind this
change is to reduce the number of ScreenPaintData transforms, which can
be very handy in simplifying item painting code.
The value of _NET_WM_OPAQUE_REGION can be out of sync with the geometry
of the window. The NETWM spec suggests to compute the effective opaque
region by taking intersection of _NET_WM_OPAQUE_REGION and the bounding
region set by the shape extension.
SurfaceItemX11::opaque() got broken after refactoring opaque region
handling in wayland surfaces so SurfaceInterface::opaque() always
returns a sane value, the computation of effective opaque region is done
in SurfaceInterface at commit time.
BUG: 455617
The drag manager of a window now can take over from anything, so that
the events to initiate a drag are not stolen by the tap handlers
(fixes the drag starts only the second time is tried issue)
On wayland drag by touch was completely broken by the supportsclosewindows check,
now the touch drag handler is always active and the check of the property is done only
when the drag is over
BUG:455268
