If both compositor and applications were to use these gestures at the same
time, that would be quite confusing for the user. This also works around
a bug in Wine that makes applications crash.
BUG: 455952
This breaks cyclic dependency between Compositor and DRM backend, there
are still indirect dependencies though. However, fewer cyclic
dependencies should make the architecture more cleaner and easier to
tweak.
Otherwise this WindowHeap type is not usable without custom delegate.
/usr/lib/qml/org/kde/kwin/private/effects/WindowHeap.qml:111:23:
QML Component: Cannot create delegate
/usr/lib/qml/org/kde/kwin/private/effects/WindowHeapDelegate.qml:21:5:
Required property windowHeap was not initialized
Switches to a shared pointer rather than a raw one. It would leak, which
in general is not a big problem but it would flood the output when
running tests with ASAN. Also it's the right thing to do.
The wayland backend changes the dpms mode when the enabled state of the
output changes. This creates problems when destroying all outputs on
shut down. The wayland backend calls InputRedirection's methods, but
InputRedirection is already destroyed by that time.
While the crash can be fixed by guarding input() in createDpmsFilter()
with an if statement, changing dpms mode in updateEnablement() doesn't
seem like a good idea because Output changes unrelated states (enabled !=
dpms mode), so let's get rid of it.
This targetOpacity is nowhere to be found. This is a relic of past
development. Currently code that needs to alter opacity based on drag
state does so externally by setting opacity on a delegate as a whole.
On wayland the code to keep windows on the current activity whilst the
window was broken was completely broken in porting. We only held the
block for the duration of the method even though the popup remained open
for longer.
On X11, when removing the window from the current activity it would not
update correctly and remain visible. The code path was as follows:
- the menu is shown an event loop is started
- we change the activities
- as we close the menu focus changes and workspace calls
UserActionsMenu::close this unsets m_window
- We then never call the blockActivityUpdates(false) at the end of
UserActionsMenu::show
This patch addresses both at once.
We get rid of the nested event loop as that was always evil. This means
slotWindowOperation no longer needs to be queued.
We perform cleanup of m_window and the activity blocker when the menu
closes which should be safer.
BUG: 456873
At the moment, a platform should provide two output lists - one that
lists all available outputs, and the other one that contains only
enabled outputs. In general, this amounts to some boilerplate code and
forces backends to be implemented in some certain way, which sometimes
is inconvenient, e.g. if an output is disabled or enabled, it will be
simpler if we only change Output::isEnabled(), otherwise we need to
start accounting for corner cases such as the order in which
Output::isEnabled() and Platform::enabledOutputs() are changed, etc.
This can be used to make our backends more multi-purpose. At the moment,
new outputs are enabled by default, but it makes sense to do otherwise.
For example, if an output is disabled by default, it would be possible
to delegate initial output configuration to layer above, to kwin.
In long term, the drm backend would need to scan connectors, create an
Output for every one of them, kwin sees new outputs and tries to apply
the initial output configuration, which includes the enabled status.
Since we don't have any means of getting notified by _NET_WM when a
windowType changes, and since KWin would handle that quite poorly, AND
since no one does that in real-world applications anyway, we might as
well mark those getters as CONSTANT, so that QML engine would stop
complaining about depending on non-NOTIFYable properties.
According to the specification, the window type should be decided before
a window gets mapped.
In X11 when a window is maximised if the client is unable to fufill the
space provided we centre align the window.
With the new floating point geometry behaviour of centreing changes.
Instead of a 1 pixel gap at the top, we get a 0.5 pixel gap either side.
When we get into the codepath to "fix" the window in `closeHeight` we
only move the top, giving us an invalid buffer size.
We don't really want to change the logic here; on xwayland with the
scaling opt-out path it's feasible for a floating sized logical size to
still be representable. This code rounds to the native unit after all
the logic has taken effect.
OutputMode provides a more robust way to refer to outputs. A mode can
have flags and things as such that are not taken into account with mode
+ refresh rate.
Code such as "screenRect.bottom() - windowGeo.bottom()" assumes that
both screenRect and windowGeo have the same type. At the moment, it's
not the case, screenRect has QRect type and windowGeo has QRectF type,
so the calculated offset will be off by one.
Instead of checking for properties needing a modeset, do atomic tests
with ALLOW_MODESET where it makes sense, and do a second atomic test
afterwards without ALLOW_MODESET to check if the modeset can be skipped.
This should ensure that KWin always does a modeset when it needs to do one,
and not do a modeset when it's not necessary. Doing this also allows
reducing the complexity of the drm backend a bit.
The DrmOutput synchronizes the enabled state with the active state,
which makes sense on one hand, but on the other hand, that's not good.
The drm backend makes a decision that should be ideally made by either
kscreen (turn on outputs before applying an output config), user, or
kwin itself.
This would also allow kwin to control the allocation of crtcs for
non-desktop outputs, which is a minor thing, but it might be useful in
the future.
It's important for tablet devices to be able to specify to which section
of the display we'll be fitting the tablet. This setting allows to
specify this by providing some options that will do so relative to the
output size.
CCBUG: 433045
This adds window filtering to the Overview effect. This satisfies both
Overview users' needs and the workflow of Windowview: When the user
starts typing, windows are filtered by default. If there is no matching
window, then the Milou UI is shown, including the option for opening a
new app is shown--the same one that currently gets shown when the user
starts typing. This leads to a very seamless experience, where the user
can type any app name and they will get it, no matter if it's already
opened or not.
infiniteRegion() is useful not only to effects but also other kwin
components, so move it to kwinglobals.h in order to make backends stop
depending on libkwineffects
This fixes the drm backend adding hotplugged gpus that belong to other
seats and makes the udev helper depend on less stuff from the layer
above backends.
The Session can be useful not only to the platform backend but also
input backends and for things such as vt switching, etc. Therefore it's
better to have the Application own the Session.
This is a too niche feature. It also doesn't have to be implemented in
the compositor. The kernel provides a way to overwrite the edid blob,
which is not specific to the running compositor.
Platform backends are provided as plugins. This is great for
extensibility, but the disadvantages of this design outweigh the
benefits.
The number of backends will be limited, it's safe to say that we will
have to maintain three backends for many years to come - kms/drm,
virtual, and wayland. The plugin system adds unnecessary complexity.
Startup logic is affected too. At the moment, platform backends provide
the session object, which is awkward as it starts adding dependencies
between backends. It will be nicer if the session is created depending
on the loaded session type.
In some cases, wayland code needs to talk to the backend directly, e.g.
for drm leasing, etc. With the plugin architecture it's hard to do that.
Not impossible though, we can approach it as in Qt 6, but it's still
harder than linking the code directly.
Of course, the main disadvantage of shipping backends in a lib is that
you will need to patch kwin if you need a custom platform, however such
cases will be rare.
Despite that disadvantage, I still think that it's a step in the right
direction where the goal is to have multi-purpose backends and other
reusable components of kwin.
The legacy X11 standalone platform is linked directly to kwin_x11
executable, while the remaining backends are linked to libkwin.
Due to the wrong buffer format, the function failed with
GL_INVALID_OPERATION error, which was silently ignored by the effect.
It resulted in the constant phantom color being returned over and over
again.
Co-Authored-By: David Edmundson <kde@davidedmundson.co.uk>
BUG: 454974
FIXED-IN: 5.24.7, 5.25.4, 5.26
Currently, defining shortcuts in useractions.cpp is done using one of
six macros, some of which allow the name that ends up as the key in
the config file to be autogenerated from an untranslated form of the
user-facing text.
Whenever a shortcut using one of these macros is renamed, the key in the
config file changes too, so users lose any custom shortcuts they had
assigned.
To avoid this, developers need to know that they have to switch to the
relevant macro that allows the name and description to be defined
separately, remember to do so, and manually set a name that matches the
old user-facing text. This can be forgotten, is not obvious to new
developers, and is a subtle source of user-facing bugs.
In addition the macros are largely unnecessary, as they are wrappers
around a custom function. We can just call the custom function
ourselves.
This commit ports away from the macros and calls the initShortcut()
instead, which resolves both issues.
cc @davidre
The original intention behind creating plugins before the workspace was
to handle the case where kwin_wayland may need to wait until outputs are
available. However, since things have changed a lot in that regard,
plugins can be loaded after the workspace now.
The main benefit behind this is that plugins can be simpler, they won't
need to track when the workspace is created.
On X11, plugins are already loaded after the workspace is instantiated.
This change adjusts the window management abstractions in kwin for the
drm backend providing more than just "desktop" outputs.
Besides that, it has other potential benefits - for example, the
Workspace could start managing allocation of the placeholder output by
itself, thus leading to some simplifications in the drm backend. Another
is that it lets us move wayland code from the drm backend.
The main motivation behind this change is to make the drm backend
multi-purpose. That's it, to make it suitable for implementing all kinds
of compositors. At the moment, there's an artificial split between
"desktop" and "non-desktop" outputs, i.e. VR headsets, which stands in
the way of that and moving the remaining wayland code out of the drm
backend for better layering and architecture.
This way we make sure that we don't explode if for some reason the
surface is destroyed (e.g. it's closed).
This will make it work exactly like the other references to
SurfaceInterface.
BUG: 456817
An effect that implements the "identify" functionality of
the screen configuration kcm. It displays a label on each
screen that identifies the screen.
Doing this as a kwin effect allows to correctly handle
the case when outputs are mirrored (on wayland) compared to
absolute positioning of windows which end up on top of each other.
This allows us to get more information about the outputs like vendor
and model and for example provide them to effects which might find
the extra info useful.
KWin requires surfacesless contexts, so this setSurface() is not needed.
This ensures that makeCurrent() won't make the opengl context current
against a surface that belongs to a removed output.
KWin requires surfacesless contexts, so this setSurface() is not needed.
This ensures that makeCurrent() won't make the opengl context current
against a surface that belongs to a removed output.
The main reason to drop multi-head support is that it has been simply
unmaintained for many many years. When implementing a feature, we don't
even bother checking if multi-head is broken, KCMs don't handle
multihead, window management features are written for Xinerama. KWin
is optimized for Xinerama-like operation mode in general, which is
provided out of the box.
If you use multihead for esoteric gpu stuff, consider using kwin_wayland!
If a DesktopView doesn't handle a keyboard navigation event it
propagates to main which then focusses the next desktop view and the
relevant window.
Empty desktops can also be selected.
BUG: 456068
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
Most xwayland clients don't know their desktop file name, so use the
StartupWMClass field in their desktop files as means to inferring their
desktop file name.
BUG: 455265
We assume that outputs in kwinApp()->platform()->enabledOutputs() are
stored in the xinerama order. However, this is not the case on Wayland
and it's not going to be changed because it increases the complexity.
This change makes Workspace::xineramaIndexToOutput() use Xinerama
extension API to map a xinerama index to the associated Output object.
With this, Xwayland applications will be able to put on outputs as
expected.
Note that xinerama indices are not cached because
Workspace::xineramaIndexToOutput() is not used in any hot code path. If
that changes, xinerama indices can be cached. The cache must be
invalidated whenever we get screens changed notify event from RANDR.
Currently, we implicitly assume that enabled outputs are stored in the
xinerama order, but with ongoing refactorings, it's easy to break that
assumption. Also, we are not going to change the DRM backend so it
stores enabled outputs in the xinerama order.
This change adds xinerama index conversion helpers in order to reduce
the number of potential regressions with output refactorings.
There was a geometry change that fixed mixing the next and current
geometries. While it did fix issues on wayland, it broke window shading
on x11 because of an obscure resize() call.
That obscure resize() had a side-effect that ensures m_clientGeometry
has the right value so the next time the window is unshaded,
implicitSize() will return a good value.
In order to make window size computation more robust, this change makes
X11Window compute the natural frame size based on cached size in
m_client, which shouldn't change when the window is shaded.
However, given how buggy window shading is and how difficult it is to
make it work right, I think that it's better to deprecate window shading
and remove it in some future release.
BUG: 450582
Currently, the highlight effect is not very visible because it only
barely peeks out of the window thumbnail. We can make it bigger by
making it peek out a little bit more, and also by including the window
title and icon (when visible) within it.
BUG: 454842
This code uses the DEF() macro which silently re-uses an untranslated
version of the string as the ID in the config file. So anytime you
change the text, a new entry will be created in the config flil and
users will lose any custom shortcut mappings.
To avoid this, use the DEF2() macro instead, which allows defining the
ID and the user-facing translated name differently.
We gain nothing with it. XCB setup logic in the Xwayland server has to
be moved to the workspace layer anyway. For example, this move of
responsibilities will be needed to support running more than just one
instance of Xwayland. Architecture-wise, it would be cleaner too.
Unfortunately, it breaks encapsulation of the Application, but this can
be taken care later.
In the desktop grid effect, dragging an empty area of a desktop to
another desktop swaps all windows on the two desktops. This change makes
sure that this matches only windows in the current activity.
Was earlier fixed in
1e0b0c881e
, but the bug was reintroduced by the QML rewrite.
BUG: 386769
Having RollOverDesktops false is more intuitive and "natural" for
new users, who may be disoriented by virtual desktop navigation
wrapping around (especially for small numbers of virtual desktops)
and not find the setting to change it very easily.
Relying on the texture matrix to normalize means we multiply every UV
coordinate with 1/scale, which leads to floating point errors and thus
errors in the UV coordinates. Instead, if we calculate normalized
coordinates directly we avoid floating point error and get proper UV
coordinates.
Longer term the plan is to make all UV coordinates normalized and get
rid of the CoordinateType altogether.
With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
We need to reset the QML Item on failure or trying to load a
different switcher afterwards will pick a wrong codepath and
also fail.
BUG: 445455
FIXED-IN: 5.25.4
Some legacy drivers either don't accept gbm buffers suitable for cursors,
or don't handle them properly. In order to work around that, always do a
CPU import with legacy and use dumb buffers instead.
BUG: 453860
CCBUG: 456306
The Screens object is created by Workspace on X11. This change makes X11
and Wayland behave more similar. As is, the Screens is a helper for
window management code, don't use it in backends. Note that the X11 backend
already uses the Screens, it needs to be addressed individually.
We now rely on auto-vectorisation to generate the appropriate SSE or
other instruction set code. We can also assume that takes care of
handling any alignment requirements and thus remove the need for manual
alignment things.
Both GCC and Clang do auto vecrization these days and testing shows that
that actually produces faster code, so dropping the SSE stuff makes
things both simpler and faster.
Without this patch the following warning is issued:
Could not convert argument 1 at
onTriggered@file:///usr/share/kpackage/kcms/kcm_kwin_effects/contents/ui/Effect.qml:129
onClicked@file:///usr/lib/qml/org/kde/kirigami.2/templates/SwipeListItem.qml:485
Passing incompatible arguments to C++ functions from JavaScript is dangerous and deprecated.
This will throw a JavaScript TypeError in future releases of Qt!
`bottomLeft()` is affected by the same issue as anything else using
bottom, that is, it is off by 1. So instead use top() + height() for the
bottom edge.
This behavior was added in order to fix a crash reported in bug report
442990. However, the analysis was not 100% correct, kwin failed to
create a placeholder because the relevant check was incorrect. The drm
backend was checking the list of all connected outputs rather than the
list with enabled outputs to decide whether to create a placeholder output.
As a safety measure the proposed behavior makes sense, however the drm
backend is not the right layer to implement it. If the last enabled
output is disconnected, kscreen should view it as a new output
setup and re-enable outputs in order to ask user what desired output
configuration should be.
This port the remaining bits in EffectsHandler from Screens. It does
make sense to deprecate or remove workspace geometry bits in
libkwineffects as the interpretation of the workspace layout is very
effect-specific, e.g. as in the slide effect.
Without this, the rowsChanged signal wasn't emitting at startup, so the
binding `highlight: kcm.desktopsModel.rows !== 2` didn't work correctly.
FIXED-IN: 5.24.7 5.25.3 5.26
The guessed repaint region is not optimal on wayland. Second, if it's a
new output, it's expected that there will be already a scene repaint
that covers all items on the given output so items don't need to provide
redundant repaint region.
The kernel doesn't disable connector objects that represent physical ports
when the output gets removed. If KWin tries to change the output configuration
without explicitly disabling the connector, atomic commits can fail.
- use kcoreaddons_add_plugin CMake macro, the other one is KWin internal
- reference embedded json metadata in section about macros
- Provide codesnippet to json metadata
- Do not explicitly define plugin id in metadata, instead we can derive it from the library name
Sometimes windows on other desktops are higher in the stacking order,
which causes them to unexpectedly jump above windows from the current
desktop in the effect.
To fix that, the z index is adjusted to be higher for windows on the active
virtual desktop, and windows from other desktops get reduced opacity in the
beginning of the animation
When we render individual component of a decoration into an atlas we
ceil the positions for the individual component parts so they don't risk
overlapping. See SceneOpenGLDecorationRenderer::render
This isn't done when we set the overall texture height. This can cause
the bottommost part of the atlas (the right edge) to go out of view.
BUG: 453745
xdg_wm_base is a global that with a single instance in our high level
wrapper. Our surface wrapper needs to get the xdg_wm_base::Resource
instance on occastion.
Currently we go via wl_client for the mapping, but this breaks down
should a client bind wm_base twice.
BUG: 456349
To allow for easier testing in development and for debugging purposes, when
the KWIN_IM_SHOW_ALWAYS environment variable is set, treat it as allowing
the keyboard to be shown, even when not using touch input.
The slide effect translates all windows as we switch desktop. In a multi
screen setup we don't want windows to enter a different screen during
this animation.
The current code masks everything to the current output. This is broken
for any window that spans across screens even slightly. It will not be
visible during the transform then appear on top at the end.
The new algorithm is, for each screen in each window we crop the painted
area to the intersection of the screen and the screen's translated
position.
ScreenPaintData provides a way to transform the painted screen, e.g.
scale or translate. From API point of view, it's great. It allows
fullscreen effects to transform the workspace in various ways.
On the other hand, such effects end up fighting the default scene
painting algorithm. For example, just have a look at the slide effect!
With fullscreen effects, it's better to leave to them the decision how
the screen should be painted. For example, such approach is taken in
some wayland compositors, e.g. wayfire, and our qtquick effects already
operate in similar fashion.
Given that, strip the ScreenPaintData of all available transforms. The
main motivation behind this change is to improve encapsulation of item
painting code and simplify model-view-projection code in kwin. It will
also make the job of extracting item code for sharing purposes easier.
If a leftmost output is temporarily disabled but outputs on the right
hand side are not moved, some windows may stop being movable because the
Workspace will return bad FullArea. In order to improve handling of
that case, make the FullArea same as the workspace geometry.
At the moment, when an IdleDetector is inhibited, it can emit the
resumed signal. It makes sense on one hand, but also it doesn't.
Inhibited != resumed.
According to the idle-inhibit-v1 protocol specification, we don't
need to emit the resumed signal:
> Likewise, the inhibitor isn't honored if the system was already idled at
> the time the inhibitor was established, although if the system later
> de-idles and re-idles the inhibitor will take effect.
Removing connectors that are still powered leads to a mismatch in atomic
commits: the crtc is still powered, but the connector also still there.
If KWin tries to disable the crtc afterwards, the atomic commits fail because
the connector needs to be disabled at the same time and it's missing from the
atomic commit request.
To fix this, whenever we fail to fetch information or get wrong data from
the kernel (like 0 modes), use the cached information instead and keep the
connector.
BUG: 456298
These are proper nouns and should be capitalized. And let's consistently
use the term "Virtual Desktop", not just "Desktop" (which can be
confused for the desktop with the wallpaper).
It seems it doesn't bring much and it may backfire. Especially don't
pass GBM_BO_USE_LINEAR as it will limit a lot the buffers that can be
created and GBM_BO_USE_RENDERING use seems to be more harmful than
helpful on most cases.
When the animation slider moved to look and feel a UI was kept within
the compositing KCM that was only visible for non Plasma users so they
still had a way to access this.
This non-plasma version still wrote to kwinrc. In theory this was fine
unless you used both. We also hit an issue where a stray
m_settings->save() call in `reenableGl` would sync the settings to the
wrong place.
This patch moves everything to write to kdeglobals and cleans up any old
entries here.
BUG: 431259
in order for qml pointerhandlers to work correctly, they need
timestamps in all events (to decide for instance when to emit a
tapped or doubletapped)
BUG:456133
This makes it so that the windowview/overview/desktopgrid effects
all use the middle mouse button to close windows.
The previous behavior of pinning window is now assigned to the
right mouse button.
BUG: 456144
The IdleDetector is an idle detection helper. Its purpose is to reduce
code duplication in our private KIdleTime plugin and the idle wayland
protocol, and make user activity simulation less error prone.
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.
