Virtual machines aren't properly supporting atomic mode setting yet, which
causes the cursor to be offset, and will cause more issues with overlay
planes. In order to prevent that from impacting users, fall back to legacy,
unless KWIN_DRM_NO_AMS is set.
BUG: 427060
FIXED-IN: 5.24.4
Some effects (AnimationEffect) transform windows without setting
PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS flag. Make the scene disable
render optimizations if that's the case.
Whether AnimationEffect does a right thing is up to debate.
Window painting is no longer split in two phases - PAINT_WINDOW_OPAQUE
and PAINT_WINDOW_TRANSLUCENT.
PAINT_WINDOW_TRANSLUCENT is used as a hint to the occlusion culling
logic to ignore the opaque region.
Given that, the handling of the opaque region can be simplified. If no
effect sets the PAINT_WINDOW_TRANSLUCENT flag, then the opaque region
can be used as is.
It's not possible to get the surface damage before calling
Scene::paint(), which is a big problem because it blocks proper surface
damage and buffer damage calculation when walking render layer tree.
This change reworks the scene compositing stages to allow getting the
next surface damage before calling Scene::paint().
The main challenge is that the effects can expand the surface damage. We
have to call prePaintWindow() and prePaintScreen() before actually
starting painting. However, prePaintWindow() is called after starting
rendering.
This change makes Scene call prePaintWindow() and prePaintScreen() so
it's possible to know the surface damage beforehand. Unfortunately, it's
also a breaking change. Some fullscreen effects will have to adapt to
the new Scene paint order. Paint hooks will be invoked in the following
order:
* prePaintScreen() once per frame
* prePaintWindow() once per frame
* paintScreen() can be called multiple times
* paintWindow() can be called as many times as paintScreen()
* postPaintWindow() once per frame
* postPaintScreen() once per frame
After walking the render layer tree, the Compositor will poke the render
backend for the back buffer repair region and combine it with the
surface damage to get the buffer damage, which can be passed to the
render backend (in order to optimize performance with tiled gpus) and
Scene::paint(), which will determine what parts of the scene have to
repainted based on the buffer damage.
They still aren't realtime animated, but by making them respond to the
realtimeGesture() call, they can use callbacks to determine if they should be shown
or not. This allows you to swipe up, have it trigger, then swipe down in the same
motion and get it to untrigger without ever having to release.
Fixed a bunch of bugs and polished the slide effect.
Plugged the slide effect into the new VirtualDesktopManager interface desktopChanging() to allow for mac os style desktop switching.
BUG: 448419 BUG: 401479
Hard to avoid as long as we don't have CI coverage yet, but that will take
a bit more time, we need KWin (and all its dependencies) to fully build
first.
The raspberry pi exposes opaque formats for the cursor plane, and interprets
them as being opaque as well... Considering that we effectively don't support
anything else with the QPainter anyways, just hardcode ARGB8888 until we paint
the cursor with OpenGl.
This reverts commit ca7fc44814.
Reverting work with no explanation is unacceptable, especially when
you've already been asked to stop multiple times.
CWG has already been contacted regarding this conduct, which is
starting to seem like vandalism of KDE's codebase. I am CCing sysadmins
and officially recommending an emergency recovation of commit access
for uhhadd@gmail.com to prevent further abusive behavior.
CCMAIL: uhhadd@gmail.com
CCMAIL: sysadmin@kde.org
This reverts commit 154528cdef.
This commit was reverted with no explanation, context, or discussion. In
the future, please discuss things like this before doing them. KWin is a
community project, not a personal playground.
CCMAIL: uhhadd@gmail.com
KColorScheme::createApplicationPalette is quite expensive and DecorationPalette::palette is called quite a lot
Cache the result and only update when needed
This fixes a bug introduced in https://invent.kde.org/plasma/kwin/-/merge_requests/2045 where it would no longer check if it should redraw the whole region unless the data clip intersected. This would lead to flickering in certain cases
BUG: 421135
Allows removing some CMake checks config-kwin.h contents. This is
supported by all compilers and required for C++17. While touching those
lines I also cleaned up an unnecessary HAVE_UNISTD_H check (glibc always
has it and and incorrect use of HAVE_SYS_PROCCTL_H.
fbdev has been deprecated and unmaintained for a while. With Linux 5.14
including SimpleDRM driver, we can drop it. (at the time of writing this
commit message, the latest Linux version is 5.16).
[1/6] Make autotests create fake input devices
The goal of this patch set is simulating user input in unit tests via
InputDevices and no longer use the Platform to fake input. This matches
more closely with how input is processed when running a full plasma
wayland session, i.e. with the DRM and libinput backends.
This line had several problems:
1. Using un-namespaced `units` properties
2. Using `width` in a Layout
3. Using largeSpacing instead of gridUnit for indentation
All are fixed with ths commit.
The QStringView::to[Number]() methods in Qt5 cause one extra allocation
compared to the QStringRef counter-part. As long as we aren't on a hot
path this is probably not worth the extra #ifdef though.
when an aurorae theme does not contain "mask" element we can safely assume that blur is not supported. In such case all blur calculations must not run at all. This will make all solid aurorae themes much lighter by default.
kwin disables ptrace for a good reason - to prevent other processes from
attaching to kwin and snooping sensitive data or taking control of kwin.
But, that will also make things such as memory statistics unavailable to
read, etc.
On the other hand, the supported platforms where kwin runs all have
security measures in places to forbid shady processes ptrace'ing kwin.
For example, on Linux it's YAMA.
On Linux, by default, a process can ptrace only its descendants. For
example, this can be used by debuggers; otherwise you would need to be
the superuser to attach to any process.
This change drops our ptrace logic in favor of system provided security
measures. It allows the System Monitor to gather kwin's memory usage
statistics and also simplifies code, the current debugger detection
logic is not really robust.
If the system provided security measures are proven to be insufficient,
we can add the ptrace disabling logic back, but it would be great to
avoid that because system monitor won't be able to gather resource usage
statistics, which can be useful for detecting memory leaks in plasma
wayland session, etc.
when aurorae decorated windows become maximized and back to normal, after a while they all start to disable blur for their decorated maximized windows.
- bug was tracked down to aurorae fault sending empty QRegions for its maximized windows. What probably happens is that because mask FrameSvgItem enabled borders change from AllBorders to NoBorder, mask FrameSvgItem calculations can not catch up
- the new approach is lighter than the previous one and simpler as margins and enabledborders for mask framesvgitem are not changed and in the c++ side no QRegions calculations are needed at all for maximized windows
- in my system with the new code changing from normal window to maximized one feels a bit snapper
the target is called ConfigCore, the relevant cmake config is not.
notably KF5ConfigConfig.cmake is the present file, so look for the
correct name, otherwise the dependency isn't found
Qt6 insists on that. We can do this either by including the moc files,
or by including the corresponding headers in the header defining the
properties, the former seems cleaner when possible.
Having blurRegion to identify if a decoration supports blur or not instead of the metadata-json way has the following benefits:
- decorations can now provide both blur or not based on user preference
- theme engines such as Aurorae do not have to enforce blur or not to their themes and they can support blur enabled and disabled themes at the same time if they want to
- blurRegion is empty by default so the Korners bug will be fixed for all solid aurorae themes. Breeze and Oxygen have set **blur:false** so nothing changes for them.
- all aurorae themes that do not require blur will free up system resources by default
Maliit does client side animation by default but can be told to disable
them using an environment variable. Since we now want to do this
animation in KWin, always disable the client side animations in Maliit.
It feels slightly weird to unconditionally add a Maliit-specific
variable, but at the same time all other solutions are more error prone
and would likely need more code.
This adds support for animating showing/hiding of the input method panel
to the sliding popup effect, if the input panel is of type "Toplevel".
This is mainly intended to animate showing the virtual keyboard and has
been primarily tested with Maliit. It replaces the client-side animation
that Maliit would do, instead doing the animation on the KWin side which
provides a significantly smoother experience.
This makes it easier to cross-compile KWin since it is no longer necessary
to have all the KWin dependencies on the host machine. This could be
partially addressed by moving the strip-effects-metadata.cpp into a
separate folder than can be built as a top-level project, thereby reducing
the dependencies to just QtCore. However, it still means we have to build
a native binary. Since all this script is doing is removing some JSON keys,
we could also use a python script and avoid the need to compile a
build-time helper program.
Otherwise when we render it, we do so upside down and screen sharing
looks broken.
This only happens when the shadow buffer is in use, so it's not all that
common.
This is an approach for aurorae engine to publish masks for its decorated windows in order to avoid out of window blurring at the decoration corners. Aurorae themes are now able to specify a **mask** element inside **decoration.svg** file like plasma themes already do. Mask is used afterwards to calculate theme's blur region.
| Before | After |
| ------ | ----- |
|||
Adjusted Aurorae theme for testing: [ROUNDED-DARK.tar.gz](/uploads/082f60ad4311e3e296b7faeeb7c97dac/ROUNDED-DARK.tar.gz)
BUG:395725
Otherwise the connection isn't severed when the layer is destroyed,
leading to crashes when screen resolution changes.
We don't actually need `this` to access `workspace()`, and we have
a guarded `output` as sender in the other case.
Notifications are really only useful in a setting with a full
shell environment where there is a notification center to display them.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Currently, if the pointer surface has to change between two surfaces,
the compositor must do the following
seat->setFocusedPointerSurface(nullptr);
seat->notifyPointerMotion(newPos);
seat->setFocusedPointerSurface(focus);
The pointer motion is needed so the enter event has correct position,
setFocusedPointerSurface(nullptr) is needed to avoid sending a bad
motion event before the leave event.
This change makes the pointer focus api less error prone by splitting
setFocusedPointerSurface() in two functions - notifyPointerEnter() and
notifyPointerLeave().
notifyPointerEnter() takes new focus surface as well as the position
where the pointer has entered the surface so the focus update can be
atomic and without any corner cases.
notifyPointerLeave() is used to clear pointer focus.
This commit expands the QImage-to-GL formatTable to include entries
for RGBX64, RGBA64_Premultiplied, and Grayscale16 image formats.
Uploading 16-bit-per-channel formats is supported by OpenGL and, with
the GL_EXT_texture_norm16 extension, GLES.
This ensures that we get a warning if the config header is not included
instead of compiling the code as if it was disabled. Interestingly, some
checks already used #if KWIN_BUILD_*, so those were generating -Wundef
warnings when the feature is disabled. Commit 886173cab assumed that all
those features were already 01, so this unbreaks the build if any of the
features is disabled.
Fixes: 886173cab ("Reduce ifdefs in Workspace::supportInformation()")
We should use the output area as the margin size as where to position
rather than the panelSize.
This ensures that the keyboard ends up in the right place right above
the panels.
This reverts commit 3d0bdc56a4.
seat->setFocusedPointerSurface() before notifyPointerMotion() is needed
to prevent sending a motion event that's outside the previously focused
surface.
BUG: 449273
It is automatically called (and documented as such) by KCModule
after the constructor is run.
This avoids calling a virtual method from the constructor.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
None of the features it adds ontop of `QComboBox` are used.
Allows to drop the dependency on KCompletion.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
Instead of having the render backends manage layers, have DrmGpu and DrmPipeline
do it. This makes it possible to unify code paths for leased and normal
outputs, remove some redirection and have more freedom with assigning layers
to screens.
It's leftover after the times when widget style was using wayland
connection. Breeze had to destroy all wayland resources before
terminating the internal connection.
Currently, the blur effect will shrink an opaque region even if it
doesn't intersect m_currentBlur.
This ensures that the blur effect won't do a stupid thing such as
clipping the opaque region of the desktop window.
We already try to ensure that the surface damage is within render target
bounds. Avoid clipping surface damage in render backend, which is a bit
excessive task and perhaps it should be done an abstraction level above.
If the main surface is translucent (e.g. it contains only the drop
shadow) but its subsurface is opaque, the "window->isOpaque()" check
will produce a false positive.
It's not guaranteed that there will be current render target in
postPaintScreen() as all painting have been completed. paintScreen() is
a much safer place to pick color.
It's not guaranteed that there will be current render target in
postPaintScreen() as all painting have been completed. Furthermore,
even the docs of the postPaintScreen() function indicate that no
painting should be done there, you can do only cleanup things, e.g.
schedule a repaint, etc. paintScreen() is a much safer place to
capture screenshot.
When casting from integer to pointer, promoting the integer to (u)intptr_t
will ensure that the resulting type can be converted to a pointer without
problems. These two casts changed in this commit trigger a warning when
building for CHERI-enabled architectures such as Arm Morello. This is not
just limited to CHERI, the cast from xcb_pixmap_t (uint32_t) to void*
should also be flagged by -Wint-to-void-pointer-cast when using Clang,
however, it appears that warning only handles C-style casts, and not
reinterpret_cast (https://github.com/llvm/llvm-project/issues/53964).
Software cursor has always been a major source of problems. Hopefully,
porting it to RenderLayer will help us with that.
Note that the cursor layer is currently visible only when using software
cursor, however it will be changed once the Compositor can allocate
a real hardware cursor plane.
Currently, software cursor uses graphics-specific APIs (OpenGL and
QPainter) to paint itself. That will be changed in the future when
rendering parts are extracted from the Scene in a reusable helper.
At this point, it's safe to assume that only X11 has weird rendering
model, which stands in the way of making rendering abstractions nice and
intuitive, so let's check operation mode. If OperationModeX11 is
dropped, this will also simplify finding X11-specific code in kwin.
This is the first tiny step towards the layer-based compositing in kwin.
The RenderLayer represents a layer with some contents. The actual
contents is represented by the RenderLayerDelegate class.
Currently, the RenderLayer is just a simple class responsible for
geometry, and repaints, but it will grow in the future. For example,
render layers need to form a tree.
The next (missing) biggest component in the layer-based compositing are
output layers. When output layers are added, each render layer would
have an output layer assigned to it or have its output layer inherited
from the parent.
The render layer tree wouldn't be affected by changes to the output
layer tree so transition between software and hardware cursors can be
seamless.
The next big milestone will be to try to port some of existing kwin
functionality to the RenderLayer, e.g. software cursor or screen edges.
The responsibilities of the Scene must be reduced to painting only so we
can move forward with the layer-based compositing.
This change moves direct scanout logic from the opengl scene to the base
scene class and the compositor. It makes the opengl scene less
overloaded and allows to share direct scanout logic.
Consider the cases where we get a touch move or touch up but we never
received a touch down before.
In the case of move, we'll simulate a touchDown right there and move on
with reality.
In the case of touch up, we'll just ignore the event as simulating could
just be more confusing.
BUG: 450338
Xcursor loading code has hardcoded search paths, in order to take into
account distros installing app data in a different location,
libwayland-cursor sets the ICONDIR to the icon directory computed based
on the install prefix.
However, that won't work with gitlab CI because it relocates binaries. A
more robust way to find cursors would be to use QStandardPaths to find
all the icon directories on the system.
Another advantage of using own cursor loading code is that it allows us
to reuse cursor images that are symlinks. For example, with
breeze_cursors, almost half of the files in the cursors directory are
symlinks.
The main disadvantage of this approach is that we would have to keep the
search paths up to date. However, on the hand, there are not that many
of them, e.g. ~/.icons, ~/.local/share/icons, /usr/share/icons,
/usr/local/share/icons. The last three are implicitly handled by the
QStandardPaths.
It's specified as a Path in the kcfg file and the KCM will replace the
/home path into $HOME, and I imagine it may do some others likethat.
BUG: 450430
Rather than assuming the input panel to always be less than or equal to
the maximized area, ensure it is. This ensures that the input panel gets
placed correctly when there maximized area is smaller, like when there's
a panel on the side.
Additionally, don't skip the entire positioning code when "m_output" is
empty, to avoid the placement not happening when Kickoff is open.
Whilst global shortcuts are blocked by grabbing the keyboard, user set
up manual scripts can still invoke a global action.
Given we already have code to deactivate when locking it makes sense to
also prevent activation.
BUG: 450331
qApp is defined differently depending on whether QCoreApplication,
QGuiApplication, or QApplication is included.
Use QGuiApplication::instance() to improve code readability.
CCBUG: 450359
qApp is defined differently depending on whether QCoreApplication,
QGuiApplication, or QApplication is included.
Use QGuiApplication::instance() to improve code readability.
CCBUG: 450359
This really should not fail unless we did something seriously wrong
on our end, such as changing GL context during paintScreen.
If we add an invalid `GLSync` to the queue it can lead to very hard
to debug crashes in seemingly unrelated parts of the rendering
process, when the queue is drained, potentially seconds after the
actual failure that occurred here.
Signed-off-by: Eike Hein <eike.hein@mbition.io>
If a window appears on the screen, the highlight window effect will try
to fast-forward animation to the target state by setting the animation
duration to 0. However, TimeLine doesn't like that because it will
eventually lead to division by zero.
This change makes the highlight window effect fast-forward the
transition to highlight or ghost state by using the complete() function.
BUG: 450323
Allows to drop the direct dependency on KDeclarative only used
for `QmlObjectSharedEngine` outside of `KCModuleQML`
Signed-off-by: Eike Hein <eike.hein@mbition.io>
paintScreen() already tries to ensure that the damage region doesn't go
outside the scene geometry. With this change, it will try to clip the
damage region to the render target rect, which saves us an extra region
intersection and simplifies code that calls paintScreen().
Having a render loop in the Platform has always been awkward. Another
way to interpret the platform not supporting per screen rendering would
be that all outputs share the same render loop.
On X11, Scene::painted_screen is going to correspond to the primary
screen, we should not rely on this assumption though!
Neither SceneQPainter nor SceneOpenGL have to compute the projection
matrix by themselves. It can be done by the Scene when setting the
projection matrix. The main benefit behind this change is that it
reduces the amount of custom setup code around paintScreen(), which
makes us one step closer to getting rid of graphics-specific paint()
function and just calling paintScreen().
This allows us to make the GLRenderTarget a bit nicer when using it to
wrap the default fbo as we don't know what the color attachment texture
is besides its size.
This means that the responsibility of ensuring that the color attachment
outlives the fbo is now up to the caller. However, most of kwin code
has been written that way, so it's not an issue.
It's effectively unused and removing it allows us to get rid of
GLTexture field, which is very useful for abstracting the concept of a
"render target" across OpenGL and QPainter backends.
It's currently being used only by the X11 standalone backend. We should
either port the X11 backend to manual dirty state tracking or waiting
until it gets dropped. The main motivation for getting rid of the dirty
state tracking in the GLTexture is that it keeps kwin open for
alternative opengl wrappers, e.g. QOpenGL, and it simplifies GLTexture
code.
Because the GLRenderTarget and the GLVertexBuffer use the global
coordinate system, they are not ergonomic in render layers.
Assigning the device pixel ratio to GLRenderTarget and GLVertexBuffer is
an interesting api design choice too. Scaling is a window system
abstraction, which is absent in OpenGL or Vulkan. For example, it's not
possible to create an OpenGL texture with a scale factor of 2. It only
works with device pixels.
This change makes the GLRenderTarget and the GLVertexBuffer more
ergonomic for usages other than rendering the workspace by removing all
the global coordinate system and scaling stuff. That's the
responsibility of the users of those two classes.
In order to support layered rendering and tiled outputs KWin needs to be
able to split rendering of outputs into multiple surfaces. This commit
prepares the drm backend for that, by moving most of the code in EglGbmBackend
out to a EglGbmSurface class, which will later be used for overlay surfaces
and rendering to multiple connectors side by side.
In doing that, this commit also cleans up the code a bit, removes a lot of
now unnecessary multi-gpu stuff and potentially makes modesets a little
bit more efficient by re-using resources more often.
This allows to track per effect dependencies more precisely. The main
problem with a library and a comment next to it saying who needs it is
that the comment can get easily outdated.
/proc/%/exec always points to the canonical/real path of a binary,
the exec field of a .desktop might contain a symlink and therefore
differ from canonical path.
Explicitely canonicalizing the path in exec prevents this mismatch.
The first move() in X11Client::createDecoration() will alter the client
size, which will result in the subsequent resize() incorrectly resizing
to a smaller window size.
In order to fix that issue, this change makes X11Client adjust the
frame geometry atomically after creating or destroying window decoration.
BUG: 449988
If the window is initially maximized, there won't be any current
decoration when XdgToplevelClient changes the maximize mode, we need to
use m_nextDecoration.
BUG: 450053
With the xdg_toplevel.configure_bounds event, the compositor will be
able to indicate the client the maximum desired surface size.
It can be used to prevent mapping too big application windows, etc.
We're setting this env variable because earlier we used it to force kwin to use its special QPA so we need to change that back to something sensible.
However setting it to Wayland breaks apps that ship their own Qt with missing or broken Wayland support.
Set it to be empty instead. Well-behaved Qt apps will use Wayland regardless because of XDG_SESSION_TYPE.
BUG: 450000
When a window leaves the current virtual desktop, we need to schedule a
workspace repaint so the compositor repaints the old region of the
window on the current desktop.
In hindsight, the scene graph must schedule a repaint, but it's not
doable with the current effects api, it will be changed with future
refactoring changes.
BUG: 444172
Otherwise we get the filename to the library and not the KPackage.
The plugin having this set is most likely a leftover, because KPackage plugins
to not need to define a library.
BUG: 449881
QPlatformScreen::virtualSiblings() must return a list of screens on the
virtual desktop, otherwise QToolTip will use
QGuiApplication::primaryScreen() instead of looking up the screen where
the decoration tooltip must be shown using QDesktopWidget::screenNumber().
BUG: 432860
recordFrame requires an openGL context. This is typically done after a
frame is rendered, but when we send a frame after a cursor move this is
not guaranteed.
BUG: 448162
Despite the argument naming, the input for WindowMotionManager::calculate is supposed to be a
delta, not an absolute time. Giving it a delta fixes the PresentWindows in the DesktopGrid.
BUG: 443971
The quads for the left and right window decorations were broken in
3b4d55837. The problem is only visible for window decorations with more
than one color.
Currently, if kwin_wayland crashes at shutdown, the launcher can
potentially spawn it again. This change addresses that issue by making
the wrapper ignore the QProcess::finished() signal.
Mixing of current and next state can create all sorts of undefined
behavior, e.g. windows not moving to the desired location or
experiencing issues when tiling a maximized window.
BUG: 449541
Currently, the Cursors::currentCursorChanged signal is wired to the
updateCursor() function which calls xcb_xfixes_hide_cursor() or
xcb_xfixes_show_cursor() depending if the cursor is hidden. However, the
currentCursorChanged signal can be emitted if the cursor changed, e.g. a
new pixmap attached, or its visibility status changes.
The zoom effect hides the pointer, but when user hovers ui elements, it
will most likely change and result in more than one xcb_xfixes_hide_cursor()
calls.
It appears like xcb_xfixes_hide_cursor() is implemented as a reference
counter, i.e. if xcb_xfixes_hide_cursor() is called two times, then you
must call xcb_xfixes_show_cursor() two times as well.
This change adds a dedicated signal to indicate whether the cursor is
hidden to avoid calling xcb_xfixes_hide_cursor() multiple times while
the screen is scaled.
BUG: 448537
With connection(), we will look up the x11 connection property on
kwinApp() object, which is less efficient than just calling a method on
the app object.
Since the base Platform::applyOutputChanges() implementation only
applies changes to enabled outputs, it's not possible to re-enable a
previously disabled output.
While there's a fullscreen effect, the fall apart effect should avoid
animating windows as it can corrupt or interfere with the active full
screen effect. This matches behavior of many other animation effects in
kwin.
BUG: 449844
QPainter won't let paint with a device pixel ratio less than 1. There
are used to be workarounds to force a device pixel ratio of 1, but they
were removed with fractional scaling corner fix.
This change makes sure that the decoration renderer forces a device
pixel ratio of 1 if the output's scale factor is less than 1 so
calculated texture coordinates match where window borders are rendered
in the texture atlas.
BUG: 449681
They're error prone and don't really work for changing modes. Having
a current mode in DrmConnector also doesn't work well together with
the transactional style of how DrmPipeline operates
AbstractClient::setQuickTileMode() no longer updates electric border
mode, which can leave AbstractClient::electricBorderMode() with an old
value at the next interactive move and potentially result in quick
tiling not work if the user decides to untile and then tile the window
again while still holding left button.
Quick tiling allows you tile a window so it covers one half or a quarter
of the screen. Electric border is basically interactive flavor of quick
tiling, i.e. it allows you to drag a window to the top screen edge to
maximize it.
Currently, it's confusing that tile geometry is computed based on the
electric border mode.
This change converts electricBorderMaximizeGeometry() in a helper that's
used to compute the tile geometry given the desired mode and output
containing the specified QPoint. With that, setQuickTileMode() won't
need to set electric border anymore, which makes tiling code more
comprehensible, but by not a lot unfortunately.
XdgToplevelClient::setFullScreen() won't change the geometry
immediately, so workspace()->updateFocusMousePosition() can be removed.
Also, input handling code takes care of updating the cached mouse
position in the workspace.
If the user wants to move a tiled window, but changes their mind and
tiles the window back to the previous position, the geometryRestore()
will be corrupted because initialMoveResizeGeometry() is the same as the
geometry of the window in the tiled mode.
This change fixes tracking of the geometry restore by precomputing the
geometry restore when starting interactive move. That way, if the window
is untiled and tiled again without release left pointer button, the
geometry restore will be set to the correct value in setQuickTileMode().
This change also adjusts the test suite so such a subtle case won't be
broken again without noticing it.
There was no handling for the drop being cancelled at all, leading to
leaked WlVisit and XtoWlDrag objects. X clients could also be confused
about the state of the drag and for example not being able to start another
drag.
BUG:449362
Flickable by default allows swiping via click-and-drag or
scrolling with the mousewheel, which is weird when the content
is smaller than the available space.
Inhibit this behavior unless there's a need for scrolling.
The present windows effect can crash because a null (0) EffectScreen can
be passed to EffectsHandler::clientArea(), which is a bug.
Use EffectsHandler::virtualScreenGeometry() to get the bounding geometry
of all outputs.
BUG: 449508
The most recently activated window can be an overlay window that covers
all screens. If its center is not at an output with the fullscreen
window, then the fullscreen window's stack position won't be lowered. In
order to fix that, this change makes isActiveFullscreen() use
Toplevel::isOnOutput(), which uses geometry info, to check if both windows
are on the same output.
Since 4881dd63 replaced the double click timer for OffscreenQuickView
with a time check, we need to make sure the timestamp from
XInput/libinput is passed on to the actual QMouseEvent.
BUG: 448477
It can also be applied to client-side decorations. As long as the
compositor can ask the client to use some specific decoration mode, the
"no border" property can be set.
The implicit cast effectively rounds the value down, which make the
refresh rate be different from what KScreen actually wrote.
A better fix would be to use integers instead of floating point numbers
but that needs to happen in KScreen.
BUG: 448778
We'd trigger updatePrimary before Xwayland had reacted to the new output
so we wouldn't end up calling xcb_randr_set_output_primary() as
necessary.
BUG: 449099
When dragging from one window to another, we may end up in a data_device
that didn't get "data_device_start_drag". In that case, the internal
touch point serial will be incorrect and we need to update it to the
serial from the seat. The serial stored in the seat is changed to
std::optional so we can properly check if it is set.
A good portion of geometry handling code was written during the X11
times. The main difference between X11 and Wayland is that kwin doesn't
know where a window will exactly be after resize() or moveResize().
In order to handle Wayland specifics, every window has a bounding
geometry that is being manipulated by move(), resize(), and moveResize().
The frameGeometry(), the clientGeometry(), and the bufferGeometry() are
not manipulated by move(), resize(), and moveResize() directly. Almost
everything that manipulates geometry should use moveResizeGeometry().
This creates a problem though, since the clientGeometry() will be
updated only after the client provides a new buffer, kwin has absolutely
no idea what the client geometry for a given move resize geometry will
be.
Another side of the coin is that decoration updates are performed
asynchronously on wayland, meaning that you cannot use border properties
for anything related to geometry handling and you should avoid using
borderLeft(), borderTop(), borderRight(), and borderBottom() in general.
clientGeometry(), bufferGeometry(), and border*() are good only if you
want to forward an event or render something. They can't be used for
manipulating the geometry.
Unfortunately, AbstractClient::checkWorkspacePosition() needs both,
which is a bit of a problem. To add more oil to the fire, contents
of a decorated window can be snapped to a screen edge. This goes against
the nature of geometry updates on wayland, where we try to indicate
the bounds of the frame geometry and avoid using client and buffer
geometries.
In order to make geometry handling more correct on wayland, this change
removes the ability to snap the contents of a decorated window to a
screen edge. This allows to avoid using the client geometry in
checkWorkspacePosition(), which is a very important function that ensures
the window is inside the workspace.
There is nothing wrong with snapping the frame rather than its contents
and that's what kwin used to do. It was changed with the removal of
"Display borders on maximized windows" option, the relevant commit
didn't provide any reasoning behind the change.
The dpi of bouncing icon may not match the dpi of the screen, which
can make the linear filter sample texels from the opposite edge when
using the default wrap mode.
BUG: 448947
setWlSource will delete the X11Source while XToWlDrag did not
finish leading to potential crashes. Since it's only set when
creating a WlToXDrag, only remove it in this case.
We can also replace the virtual with a type check if we have to do
it anyways which also makes it clearer what is going on.
Detected using ASAN, declaration of the type is:
typedef union xcb_client_message_data_t {
uint8_t data8[20];
uint16_t data16[10];
uint32_t data32[5];
} xcb_client_message_data_t;
The SeatInterface cleans up currentSelection and currentPrimarySelection
when the AbstractDataSource::aboutToBeDestroyed() signal is emitted, but
since the data source and primary data source have parent objects, they
can be potentially destroyed without emitting the aboutToBeDestroyed()
signal and thus leaving dangling pointers in SeatInterface.
CCBUG: 449101
This will take care of showing user-visible error messages in case the
plugin does not exist.
While we get a log message from KCoreAddons with the change of 728b449891,
the user does not get prompted. Especially if the kcmshell/systemsettings
was not opened from the command line, spotting those error messages is more difficult.
Drag and drop objects slightly outlive wayland's DND concept as we have
to cancel the client and wait for a response.
This normally is fine, except in the case that the drag ended because
the sender quit.
Calling setWlSource on drag ends creates a matching pair with
Dnd::startDrag where we first set the source and has parralels with
clipboard.
Selection::handleSelectionRequest checks for the presence of a source.
I could not reproduce the original bug.
BUG: 448920
While in principle Mesa should already check if the buffer can be scanned
out, this may not always work. If we can't create a framebuffer object for
the buffer, fall back to compositing.
CCBUG: 448818
XCURSOR_SIZE * scale factor is not the way to compute the current cursor
size. For example, with breeze cursor theme at an output with a scale of
2 and cursor size 24, cursor images will have the effective size of (64, 64).
Also, the cursor can change when passing over user interface elements.
In order to accommodate for all of that, this change makes kwin reserve
enough of space for a cursor of size 256x256. "256" is a magical number
that comes from DRM. With many drivers, the maximum cursor size is 256.
BUG: 448840
If there's only one configure event that changes the position of the
window and it gets acknowledged but no buffer is attached yet, and a new
configure is sent, then the ConfigurePosition flag won't be inherited
by the new configure event and the window will be misplaced.
In order to fix that, this change makes XdgSurfaceClient pop the last
acknowledged configure event from the m_configureEvents list only when
it's about to be applied for sure.
BUG: 448856
Encoders are not really relevant for the test result, except that one of
the encoders for the connector must be compatible with the crtc.
The kernel usually exposes only a single encoder per connector for this
reason, but if a driver exposes multiple then that means KWin will do a
lot more tests than is necessary.
In order to prevent that from happening, do fewer syscalls and simplify
code, only check supported encoders once per connector.
When setting the default value for `ElectricCornerRatio` in the UI form
we also need to update the default indicator for this field.
*Default value for this setting is 25%*
| BEFORE | AFTER |
|---|---|
|||
BUG: 448886
FIXED-IN: 5.24
Historically, noBorder() was used for two things:
* as a substitute for AbstractClient::isDecorated()
* to determine whether the AbstractClient should have a decoration
With async decoration updates refactoring, a few things around
noBorder() have changed, which exposed an existing bug in the handling
of borderless maximized windows.
It's possible to have a case where an initially maximized window makes
an xdg_toplevel.set_maximized request before the initial commit, but
creates the decoration object after the initial commit.
Since XdgToplevelClient::userCanSetNoBorder() would return false when
maximize() is called in XdgToplevelClient::initialize(), m_userNoBorder
won't be updated and therefore the window can end up having a server
side decoration.
Previously, it wasn't the case because kwin would do nothing if the
decoration is installed and its preferred mode changes after the initial
commit but before the surface is mapped. With async decoration fixes,
kwin would react as expected, which unfortunately has exposed the bug.
The root cause of the problem is the fact that noBorder() is overloaded,
which makes it error-prone.
This patch changes how the noBorder property is treated. Now, it only
indicates whether the compositor wants the window to have no borders. If
noBorder() is true, it means that the compositor doesn't want the window
to have a server-side decoration; on the other hand, if noBorder() is
false, it doesn't imply that the window should have a decoration.
BUG: 448740
X11Client can grab pointer when starting interactive move or resize so
all pointer events go to it and kwin can update the move resize geometry
based on the current interactive move-resize mode.
However, on Wayland, X11Client::motionNotifyEvent() is disabled and
pointer events go through a code path that requires no X11 pointer grab.
This signal is sent back to the ksldapp after the greeter has registered
a window with the compositor. Only once ksldapp gets this signal does it
release the lock delaying suspend.
With xdgshell/layershell we have a roundtrip of configuring before the
window is even exposed, so we move to a different signal. This also
helps encapsulate lockscreen code.
Ideally we want to add code tracking frame rendering per screen tracked
too, but that would be based off this change.
CCBUG: 316734
On wayland cursors are managed by kwin. During a move resize operation
kwin updates its own cursors in pointer_input. There is no need to sync
any cursor changes back to the X server as we end up setting it twice.
19c471405e7eb4b6026db24d776d205125dbc013 introduced a regression if
there are two gbm backend and the backend fail to choose drm format.
This fix does two things:
1. Current buffer format should not be reset after create new buffer,
otherwise current.format may just be empty after resetOutput.
2. force xrgb 8888 need to be set on the primary backend.
BUG: 448790
If the user is currently typing, do not highlight windows based on the mouse position. If the user types a window title before the effect opening animation is finished, he ends up in a situation where only one window is on the screen but it is deselected (because the mouse is not on the window) or another window is selected because of the mouse. With this change, the mouse input does not overwrite the window highlighting based on the search entered **if the user is currently typing.**
As the placeholder output gets added or removed in response to other outputs
getting enabled or disabled, the output list may change while iterating over
them and applying changes.
BUG: 448454
BUG: 448474
CCBUG: 448697
FIXED-IN: 5.24
Currently, finishInteractiveMoveResize() relies on a hidden behavior
in the sendToOutput() function that makes it treat fullscreen windows
differently, which is confusing.
With this change, finishInteractiveMoveResize() will use the
checkWorkspacePosition() function to make sure that the geometry of the
fullscreen window is adjusted to the new monitor. It allows to make
sendToOutput() more straightforward.
It also fixes checkWorkspacePosition() using wrong geometry type in the
fullscreen window path.
A while ago, geometryRestore() had to have a sane value even if the
window is not maximized because checkWorkspacePosition() used it.
Since checkWorkspacePosition() doesn't use geometryRestore() anymore, we
can stop updating the geometry restore.
geometryRestore() is no longer updated after mapping the window, so
setQuickTileMode() has to update geometryRestore() explicitly to the
correct value.
With this change, geometryRestore() will be updated as follows:
* if the window is tiled, geometryRestore() is valid, nothing to do
* the window has been dragged to the top edge, set geometryRestore() to
the geometry that the window had when starting move
* otherwise, use the current move resize geometry
After calling setMaximize(), the window should cover the maximize area.
The commit message of 516ea86341 doesn't
explain why only the y coordinate is enforced or why the x coordinate is
not enforced.
In order to make some sense of the code, this change removes the semi-
random enforcement of the y coordinate.
If the window is inactive and it enters fullscreen mode for some reason,
it can create a situation where keyboard goes to a window occluded by
the fullscreen window.
This change makes XdgToplevelClient::setFullScreen() not raise the
window. It's the responsibility of whoever requested the fullscreen mode
change.
If the configure event is acknowledged, the window's stack layer will be
invalidated and recomputed. If the window is active, it will be promoted
to the ActiveLayer, otherwise its stack position won't change.
dontInteractiveMoveResize() was added to workaround kwin sending bad
configure events when double clicking mpv to make it fullscreen.
With async geometry updates fixed, dontInteractiveMoveResize() can be
finally removed.
Another reason to remove dontInteractiveMoveResize() is that it can make
kwin crash with a debug build. For example, if you enable resizing
maximized windows in breeze decoration settings and resize a maximized
window, kwin would eventually crash in
the AbstractClient::handleInteractiveMoveResize() function because neither
isInteractiveMove() nor isInteractiveResize() return true.
Based on the implementation of wl_display_connect, WAYLAND_SOCKET is
always preferred over WAYLAND_DISPLAY, which means it is OK to have both
of them set. This allows subprocess of input method to have the correct
WAYLAND_DISPLAY variable set.
As formats are per output and also checked on crtc changes, there
is no reason to restrict used formats to those that are supported
by all primary planes anymore.
When the crtcs get switched around between outputs, their primary
planes and thus the supported formats also get switched around. In
order to make sure that doesn't cause any problems, always check
whether or not the format+modifiers used are supported.
