In 5.24, the same code path is used for testing direct scanout, so that
causes false negatives. Generally though, the user setting shouldn't be
touched, it's not really proper feedback for the driver or KWin having
problems.
Some modes can have the exact frame timings but different flags.
Currently, the mode comparison function doesn't take that into account
which can result in the drm backend setting the current mode flag
incorrectly.
If no mode has the current flag set, the first mode object will be
announced twice.
There's also no benefit from sending the current mode as last. If the
current mode changes, the compositor will send the current_mode event,
not the mode event.
BUG: 452318
Since the Toplevel.output property is properly synchronized with the
frame geometry, Workspace::clientArea() can use the output property
instead of looking up the screen. It makes code intuitive and removes
unnecessary lookups.
Currently, if geometry updates are blocked, the Toplevel.output property
won't be updated. On the other hand, it's reasonable to use the output
property instead of manually looking up the output in window management
code, e.g. Workspace::clientArea().
In other words, using the Toplevel.output property is like walking on a
mine field, things can blow up. You can't use Toplevel.output even if it
makes perfect sense.
This change ensures that Toplevel.output property is always kept in sync
with the frame geometry. Unfortunately, this means that the output
property no longer can be updated when the frameGeometryChanged() signal
is emitted. It has to be done in moveResizeInternal() method.
If the blob is fetched while there is no kernel-visible reference to it,
the driver may re-use the blob ID. When DrmProperty is created or updated,
KWin holds a reference on the blob via drmModeObjectProperties, so this
should prevent any possible issues.
CCBUG: 449285
Using the global coordinate system when specifying output layer damage
regions would be very confusing. In order to make the coordinate system
comprehensible, use the layer-local coordinate system.
The infinite region is used to tell the Compositor when it needs to
repaint the entire layer.
In xdg_activation_v1, if a process fails to negotiate activation, at
least decorate it as demanding attention.
This will give apps ways to indicate attention is required. It can can also
help detect clients doing weird things.
Whilst a subsurface must have a parent at the time of creation, the
lifespan is not guaranteed afterwards.
It's a weird thing for a client to do, but we need to not crash
afterwards.
If the parent surface is destroyed we should consider the surface
unmapped.
BUG: 452044
In the current form any client committing multiple times without
attaching a buffer would unset the cached state and trigger an error.
It's legal (though weird) to commit multiple times before attaching a
buffer.
We should only reset the state if we commit an empty buffer after having
committed an existing buffer. This brings us in line with XdgShell.
Right now Workspace and SessionManagement were entangled with
SessionManager being a dumb class that just signalled to Workspace to do
the work.
The code, however, lived in sm.cpp despite being part of workspace.
This commit is an initial cleanup to strip some X11 specific features
from Workspace and move towards having the right code in the right
files. It should hopefully help get us in the right direction we get
some wayland session management.
Behaviour should be unchanged.
- added option to remove the frametime graph
- added option to remove the "this is a benchmark" message
- location of the fps counter is now on the "active" monitor by default
- removed the hard-limit of 100 for the FPS counter
- added option to color the text based off the FPS value
When changing global settings like switching between light and dark
themes the result is currently quite messy. Apps update in a scattered
order and a jarring change.
The solution is heavily inspired from Gnome, we cache the window for X
milliseconds, then perform a crossfade between the cache and current
contents.
It does mean any video is paused for half a second, but pragmatically
it's not really bothersome.
On receipt of an explicit DBus method call we create a cache and start
animating. The explicit method call is needed so that we can guarantee
kwin has a fully copy before a client might change.
Use of an offscreen texture is used so that we include any window
decorations. The DeformEffect effect is repurposed as it has most the
relevnat logic if we remove the live updating.
Doing that breaks when the input device has a very high resolution, which
is the case with touchscreens for example. The minimum delta of 5 is an
arbitrarily chosen value that can be changed if needed
When the system goes to suspend and screen locking for suspend is enabled,
suspend is inhibited until ScreenLocker::KSldApp::self()->lockScreenShown()
gets called, in order to make sure that the lockscreen is shown before the
system goes to standby, and thus also when the system wakes (instead of
potentially sensitive user information).
However, signalling that when the lockscreen gets mapped can't work reliably,
as it's then a matter of timing whether or not KWin actually presents an
image with the lockscreen before suspending. To fix that, this commit replaces
that logic with only calling lockScreenShown once every output actually got a
lockscreen presented.
* Makes the close button on thumbnails always visible: besides making it usable on touch, makes it more usable with mouse as well
* add a drag down gesture to close windows, moving opacity to zero while dragigng down to signal the window will be destroyed
* restore behavior animations: animate changes in thumbnails size or positions when not in drag mode or drag gesture to not make jarring sudden changes after closing a window or at end of drag mode
With this change, the Workspace would provide clientArea() overloads
that take only AbstractOutput and VirtualDesktop. integer ids are
obsolete as they are unstable.
When modesets are necessary, they are attempted when an output on the given
GPU gets presented. With multi-gpu setups however, the situation can arise
where there is only one disabled output on a GPU; in that case KWin eternally
waits and never properly turns off the display.
In order to work around this, explicitly call DrmGpu::maybeModeset when
an output gets disabled.
BUG: 449878
FIXED-IN: 5.24.4
