I just got a build failure because I hadn't updated KDecoration to
include 195bcf36df.
Bump the minimum version to trigger a CMake error instead of a
compilation failure. Since we expect to be using the same version of
KDecoration as KWin, this change uses ${PROJECT_VERSION} as the minimum
version.
Currently, the pointer is moved to the center of the workspace. However,
on a multi-monitor setup, the workspace center may not be the same as
the center of the output it's on. That's the case with my setup -
1920x1080, 1920x1080, 1080x1920 (the monitors are laid out in a row from
left to right).
This change improves the default placement of the pointer by actually
moving it to the center of the screen that contains the workspace center
so the pointer doesn't end up at some "random" position from the user's
point of view.
Edge geometry has width and height, so we need the correction for
approach geometry of bottom and right corners.
The other edges are fixed as well.
BUG: 442973
On X11, there are four input models. With some input models, it's okay
if the window manager calls XSetInputFocus(), with others, the wm has to
ask the client to make a XSetInputFocus() request.
If kwin wants a client to take input focus, kwin will add the client
to the should_get_focus list, which contains all the windows that
are about to get input focus. Clients are popped from the list upon
receiving FOCUS_IN events.
A client will be added to the should_get_focus list even if kwin thinks
that the client already has input focus because communication between
the wm and xorg is async, anything can happen with input focus in meanwhile.
On the other hand, the wm may sometimes focus the null window if no
window should contain the input focus. The issue is that the
should_get_focus list is not cleaned up in that case, which can lead to
Workspace::mostRecentlyActivatedClient() returning wrong client and
possibly other async related issues.
We don't have such madness on Wayland as the compositor is in charge of
handling input focus.
This change makes Workspace::focusToNull() clear the should_get_focus,
which is reasonable. We need to deactivate "in-flight" focus requests.
This also fixes the bug where fullscreen Wayland windows don't go above
docks and panels due to Workspace::mostRecentlyActivatedClient() returning
bad client.
BUG: 439405
BUG: 395919
Currently, kwin crashes at shutdown because the idle poller plugin is unloaded when exit handlers are run, after the waylandServer() is destroyed. This results in null dereferencing.
BUG: 443268
Xwayland will re-create the wl_surface object if the X11 window is
unmapped and mapped. That, and the fact that the order in which the
WL_SURFACE_ID client message event is received and the wl_surface object
is created is undefined can cause the following bug:
* WL_SURFACE_ID is received
* the old wl_surface object is destroyed, m_surfaceId is reset to 0
* new wl_surface is created but because m_surfaceId is 0, it won't be
associated with the x11 window
This change ensures that kwin will associate the wl_surface with x11
window by making it not reset cached surface id when the old wl_surface
is destroyed.
However, we cannot leave m_surfaceId as is because wayland aggressively
re-uses object ids so kwin can associate wrong surface with x11 window.
To prevent that, this change also makes Toplevel::setSurface() reset
cached surface id.
CCBUG: 442936
CCBUG: 426069
It's not necessary, the placeholder output already gets created in DrmBackend::removeOutput
if necessary. More improtantly it's missing the check for shutdown, which
may cause issues if the computer is turned off while no outputs are connected.
clientArea() was changed to forbid "-1" screen ids, but it seems like
the thumbnail aside effect can pass it to refer to the active screen.
This change makes the thumbnail aside effect handle "-1" screen id case
explicitly. It will be also useful for EffectScreen transition.
BUG: 443166
If the virtual desktops rule is created, only the last virtual desktop
the window is on is going to be checked.
With this, all virtual desktops that the window is currently on will be
checked.
Technically, it's an api breaking change, but the window rules kcm is
the primary user of queryWindowInfo() so I don't think it's a big deal.
KPluginMetaData::findPlugins only returns valid json metdata, the previous
check was accidentally kept for the condition that the plugin provides a theme engine.
BUG: 442978
FIXED-IN: master
Blobs are not reference counted if used by other drm master, if kwin
re-uses a deleted blob in an atomic commit, it will fail. For example,
on my computer, this happens when kwin starts after xorg.
Besides that, kwin may try to destroy blobs that it doesn't own, which
is not fatal but it's strange to do so.
CCBUG: 442603
CCBUG: 439873
While findWorkingCombination should never fail, in the case it does
KWin should not crash. To achieve that simply restore the old config
in case of failure.
CCBUG: 439873
When libinput tears down, it may access the Session object. This change
re-jitters the shut down logic so the Session object is guaranteed to be
valid when libinput stuff gets destroyed.
BUG: 442104
ksmserver provides the backing window (the hidden black one) for the
lockscreen. We don't want to animate this fading out.
It no longer provides the logout prompt since several plasma releases.
DrmGpu::updateOutputs is now changing the state of some drm properties
without changing the fitting output state (namely RenderLoop inhibition)
which can lead to rendering being inhibited indefinitely in some cases
Software-based clipping is naive. It maps the clip region from the
global screen coordinates and intersects it with window quads. If the
window is transformed, the quads won't be clipped as expected.
Unfortunately, the OpenGL scene enables software-based geometry clipping
if the screen transformed. It's not clear why it does so, perhaps as a
performance optimization? Either way, this produces incorrect results
when the screen is scaled.
BUG: 440940
This makes ExpoLayout easier to maintain. As is, the main issue with it
is the number of layout algorithms.
With this, the ExpoLayout is going to have two layout algorithms - one is
very simple and the other not so.
