We animated from 1.0 to 0.0, however this does not take into account
that a previous effect may also have adjusted the opacity.
We should multiply accordingly.
The current code has multiple index-based for loops iterating over items we get from XCB
Dealing with raw indices is error-prone and not pretty
By using std::span we can replace these loops with range-based for loops
Also remove some intermediate containers that aren't neccesary
We currently have "windows from current desktop" and "windows from
class" but not one combining both. This adds that mode along with a
(default empty) shortcut and border activation.
BUG: 413342
This fixes makes ExpoLayout independent of its position on a screen,
which in turn stops it from randomly reflowing while dragging a virtual
desktop across desktop grid. It also removes an unwanted animation at
the end of activation of desktop grid: desktops move in place and then
windows proceed to adjust themselves resulting in a double animation.
FIXED-IN: 5.25.5 5.26
Two things about the code were wrong:
1. m_current is used in updateBlob() but was only updated afterwards
2. the assumption that the property having the same ID means it has the
same blob contents is not always true
BUG: 449285
It only uses the `KWIN_EXPORT` macro in plugin.h.
kwinglobals.h comes from libkwineffects and not kwin core.
(`KWIN_PLUGIN_VERSION_STRING` comes from config-kwin.h)
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Inheriting "active" state was meaningless, since "active" state binds
position to a ExpoCell which itself is in a disabled state.
FIXED-IN: 5.25.5 5.26
When no qml items manage the arrow key event, the root item will manage it looking to give focus to a view in the given direction derived from the arrow key
BUG:455783
Right now we update QtQuick views after a composition has rendered so
that we'll have them ready for our next frame.
One of my machines (With X11 + nvidia) was quite stuttery, profiling
shows we spend a huge amount of time with the CPU blocked waiting for
the vblank from the previous main compositing to finish swapping before
we could start processing the QtQuick rendering. Time when the CPU is
blocked is wasted time.
This patch does mean kwin's compositing cycle lasts longer but a recent
patch changes the rendering policy when we start a fullscreen effect anyway so
hopefully that should still give us enough time to render that first frame in time.
Since the screen number is well-known, we can look up the default
screen on demand. Note that xcb_get_setup() is pretty cheap as it
simply returns a const pointer to pre-allocated data.
Use SurfaceInterface::inputSurfaceAt when deciding which surface are we
entering when sending a pointer event from a touch, in case it falls
onto a subsurface.
BUG: 452967
This allows us to unify the X and Wayland codepaths that currently go
through window-system specific IPC. It also allows us to easily track
who called "setShowingDesktop" and cancel the effect when that client
disappears.
CCBUG: 449445
This is most likely just an oversight/omission from the times when the
component was actively developed. There are five states total, including
one for realtime interactions; four others need to be transitioned to.
Due to nondeterministic nature of signal propagation in QML, changing
both targetScale and state depending on dragHandler's activity could
result in targetScale wrongly updating before the state change(and thus
applied property changes and subsequent animated transition).
This fixes a bug when a window dragged to the top (but not onto another
desktop) would animate its position back to its original position on a
heap, but the scale would remain constant until the end of animation
and only then rapidly jump back to a normally scaled state.
Quad generation needs a valid surface pixmap. This did not surface
before as the pixmap was only accessed when looping the region which
typically was empty without a pixmap.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
This uses the previous pixmap if the current one is invalid,
which ensures the generated quads have sane coordinates.
The issue caused flickering while resizing Chrome after
2f4fa23e61
While at it, move `size` out of the loop as it doesn't change.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
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
