In the KPluginSelector we don't have the possibility to set the args for
each KCM. Because of that we use the metadata of the KPluginFactory as a
fallback to read the plugin keyword, which specifies the KCM we want to display.
This requires kcmutils 54b196a9bad88732debe0b49111af4755268f09f, which landed in the last release.
BUG: 445667
The person that added krunner search integration uses vim. It seemed
intuitive to that person that the Escape key should quit the search mode
instead of quitting the effect. But it seems like more intuitive thing
is to actually stop the effect.
BUG: 445708
If the opacity property is set to 0, the item will still receive mouse
events. One either needs to set the enabled or the visible property to
false to ensure that the WindowHeap receives no mouse events.
The reason for setting the opacity to 0 instead of the visible property
to false was that I thought later will nuke the paint node, but it seems
like that's not the case.
BUG: 445707
This is needed to ensure that mouse release events go to the view that
received mouse press events; otherwise some views can get stuck in a
state thinking that button xyz is pressed.
Currently, cursor shape set by QtQuick is not sync'ed, which can be seen
as the pointer not changing its shape to i-beam when hovering the search
field.
Currently, every time you launch the overview effect, QtQuick will go
out and parse QML files. With the overview effect gaining more features
and the code size getting bigger, it takes more time for the overview to
present the first frame after it got triggered.
With this change, the overview effect will keep the ScreenView
QQmlComponent object around that can be used to avoid reparsing qml code
every time the overview effect is launched.
It also ports the Overview effect from de-facto deprecated qml context
to initial properties, which yield slightly better startup times.
BUG: 445666
This allows effects to support touch input.
Unfortunately, Qt's TouchEvents require the full touch point state,
whereas KWin's internal touch handling only deals with one point at a
time. So we need to keep track of the touch state in EffectQuickView and
pass that on to Qt. Additionally, we need a QTouchDevice as lots of Qt
code depends on it.
On my Nvidia machine there was a massive lag exitingthe overview effect.
Hotspot showed it as being in QOpenGLVertexArrayObjectPrivate::destroy.
In this method we clean up some shared objects used in the context when
the context closes.
In order to do this we need the context to be current. If it is not
current Qt currently internally creates a temporary offscreen surface.
To fix this we need to have our context current during destruction,
which includes changing order so it is destroyed before the surface.
With this change, user will be able to press Tab and use Enter, Delete,
and F2 keys to activate, remove, and rename virtual desktops, respectively.
Co-authored: Fushan Wen <qydwhotmail@gmail.com>
If a window wants to be initially shown in fullscreen mode, it will
issue an xdg_toplevel.set_fullscreen request before the first surface
commit.
If a window wants to be shown in fullscreen mode and there hasn't been
any first surface commit, kwin will cache the request and apply
fullscreen mode when checking window rules in the initialize() function.
On the other hand, window rules are disabled for plasma surfaces. The
motivation behind that was to forbid user from messing with plasma's
surfaces (this change was suggested during redesign of xdg-shell
implementation).
As it turns out, there are cases where plasma may ask to show a window
in fullscreen mode, which also has a plasma surface installed, e.g.
fullscreen application dashboard.
In order to fix the dashboard, this change allows window rules to be
applied to xdg-toplevel windows that also have plasma surfaces installed.
As is, xdg-toplevel surfaces and plasma surfaces are very different in
nature. Adding more quirks to handle plasma surfaces in
XdgToplevelClient is not worth the effort and there are better
alternatives, e.g. layer-shell.
Based on user feedback, it will be great to have krunner functionality
integrated in the overview/present windows effect.
This change ports the overview effect to Milou for search results. With
it, one can search for existing windows or launch new applications.
BUG: 445207
kwin-strip-effect-metadata needs to run on the host. First, one needs to
build it, e.g.
cmake --build build-native --target kwin-strip-effect-metadata
then when cross-compiling, point cmake to the native build directory, e.g.
cmake -DKWIN_HOST_TOOLING=${path}/build-native
This improves plugin loading times. As is, the main issue is the number
of builtin effects and the fact that each has a lot of translated
strings, which combined adds up to noticeable loading times. KWin itself
will never read those translated strings, it only needs two pieces - the
plugin id and whether the plugin is enabled by default.
This change adds a little helper to strip unnecessary info from metadata
files.
Fixes a crash I have with dpms + suspend, which was caused by the udev
event for updating outputs being called before the output got enabled
again. When DrmGpu::updateOutputs got called it removed the crtc from
the inactive output and then disabled the output afterwards. Instead,
only remove crtcs if an output is really disabled.
This also allows to generalize the logic for lease outputs, and could
in the future allow for faster dpms on/off switching.
This unifies frame hooks for OpenGL and QPainter render backends. There
are a couple of reasons why it's a good idea - it provides one mental
framework to start painting a frame, the Compositor will be able to
start and submit frames. The last one is very cool because it gives the
Compositor more power over compositing.
Besides unifying frame hooks, this cleans up a bit the arg naming mess
in endFrame(). As is, "damage" and "damagedRegion" are very confusing
names. "damage" arg has been renamed to "renderedRegion," because that's
what it is. The renderedRegion arg specifies the region that has been
repainted by the Scene. It's different from the damagedRegion as that
one specifies the surface damage, i.e. the difference between the
current and the next frame, while the renderedRegion may include a
region that had to be repainted to repair the back buffer. The main
reason why we need renderedRegion is the X11 platform. On Wayland, it's
unused.
In the future, we will need to extend this api with output layers.
The lanczos filter checks the screen size before rendering in
LanczosFilter::updateOffscreenSurfaces(), so this is not needed.
This simplifies lifetime handling of the lanczos filter, e.g. we
don't need to bother with opengl context anymore, and makes the
scene use less Screens' features.
On Wayland, a window can have subsurfaces. The spec doesn't require the
main surface and its sub-surfaces to have the same scale factor.
Given that Toplevel::bufferScale() makes no sense with Wayland windows,
this change drops it to make code more reasonable and to prevent people
from using Toplevel::bufferScale().
With a persistent vbo, kwin will allocate one big enough buffer and
allocate memory out of it.
In order to prevent overwriting vertex buffer data that is currently
being accessed by the GPU, fences are inserted at the end of frame.
The signaled fences are destroyed after the buffer swap operation, which
seems a bit odd because the just inserted fence most likely won't be
signaled. Perhaps it's a historical artifact?
This change rearranges fence cleanup so it's performed right before
starting a new frame. With it, kwin will most likely re-use the
previously used memory chunk because there will be plenty of time for
the fence to become signaled.
Another motivation behind this change is to make refactoring SceneOpenGL
code easier. As is, m_backend->endFrame() is wrapped in
GLVertexBuffer::endOfFrame() and GLVertexBuffer::framePosted(). With
that, the Compositor can't call m_backend->endFrame(), which can be
desired for cleaning up render backend abstractions.
Currently, when screencasting a window, kwin may render a window into a
temporary offscreen texture, copy that offscreen texture to the dma-buf
render target, and discard the offscreen texture.
Allocating and deallocating offscreen textures is inefficient. Another
issue is that the screencast plugin uses Scene::Window::windowTexture().
It's a blocker for killing scene windows.
This change introduces a base ScreenCastSource type. It allows us to
move away from Scene::Window::windowTexture() and make the dma-buf code
path efficient with applications such as Firefox that utilize
sub-surfaces.
With the ScreenCastSource, kwin can also provide screen cast frames with
arbitrary device pixel ratio.
Like top level clients, apply plasmashell roles to popups as well (limiting them, don't allow dock or desktop roles in poups as they don't make sense)
This makes possible to recognize plasma tooltips as tooltips, treating them in a way closer to X, and makes morphingpopups work on wayland
After user edits the name of a desktop, the search field is no longer
focused. If the user starts typing text, one could expect that it will
be forwarded to the search field without requiring a click.
This change forwards unhandled key events to the search field to ensure
that searching is intuitive.
Since binary effects are installed in their own directory, checking
service type is redundant. Also, KPluginMetaData::serviceTypes() has
been deprecated.
Task: https://phabricator.kde.org/T14483
The ifdefs for have_gbm obfuscate the code unnecessarily - the drm backend
is not a great experience with qpainter, so in practice noone should ship
it without gbm anyways.
The Compositor contains nothing that can potentially get dirty and need
repainting.
As is, the advantages of this move aren't really noticeable, but it
makes sense with multiple scenes.
Backend parts are far from ideal, they can be improved later on as we
progress with the scene redesign.
The main idea behind the render backend is to decouple low level bits
from scenes. The end goal is to make the render backend provide render
targets where the scene can render.
Design-wise, such a split is more flexible than the current state, for
example we could start experimenting with using qtquick (assuming that
the legacy scene is properly encapsulated) or creating multiple scenes,
for example for each output layer, etc.
So far, the RenderBackend class only contains one getter, more stuff will
be moved from the Scene as it makes sense.
The proprietary NVidia driver now supports gbm, which vastly improves the
user experience. For older devices that will not get gbm support dropping
EglStreams will likely not have a big impact as it has several session breaking
issues anyways.
By removing the backend a lot of logic can be simplified, most notably multi-gpu.
The current "Minimize Overlapping" window placement tends to position
windows in locations that seem completely random, typically in a screen
corner. It is doing this because, true to its name, it is trying to
avoid overlapping other windows as much as possible. However in practice
this is rarely helpful. When the user opens a new window, it's because
they want to use it, and positioning the window far from where the
user is likely to be looking is counter-productive. This is even more
true on today's large and wide displays, where placing the window in a
corner may position it entirely outside the user's current field of
vision. We get bug reports about this exact issue for notifications
(which always appear in a corner by default) by users of such screens.
For notifications, this can be justifiable because notifications are
designed to be ignorable; app windows on the other hand, are not.
As a result, I commonly see Plasma users open windows and then
immediately, reflexively grab the window's titlebar and drag it to the
center of the screen. I have seen my wife do this. I have seen every
YouTube reviewer of Plasma do this. I have even see fellow KDE
developers at sprints do this. It seems like quite a common impulse
to want a newly-opened window to appear in the center of the screen,
which is where the user is likely to already be looking.
Thankfully, KWin already has a window placement mode that does this
automatically: "Centered". Accordingly, this commit changes the default
KWin window placement mode from "Minimize Overlapping" to "Centered".
No kconf migration script is provided because this is a better default
for most people in most cases, and existing users are highly likely to
appreciate this change.
The main motivation behind this change is to move management of drm
blobs out of property wrappers in specialized wrappers to simplify state
management with blobs.
Connector mode blobs are created on demand.
When we switch CRTCs it can happen that a CRTC would stay enabled yet has
no connectors anymore. In this case the kernel may reject our atomic commit,
which would cause the modeset to fail. To counteract that, properly disable
unused drm objects
Currently KWin is combining modesets with presentation, which causes problems
when multiple monitors are used and crtcs need to be switched around, because
taking away a CRTC from another output causes the driver to disable the
other output. In order to avoid such problems, delay presentation until
all pipelines are ready to present and then do a modeset with a single atomic
commit. To process the resulting page flip events properly this commit also
ports KWin to page_flip_handler2 and changes how the pageFlipped and
notifyFrameFailed signals are processed.
Hardware constraints limit the number of crtcs and which connector + crtc
combinations can work together. The current code is searching for working
combinations when a hotplug happens but that's not enough, it also needs
to happen when the user enables or disables outputs and when modesets are
done, and the configuration change needs to be applied with a single atomic
commit.
This commit removes the hard dependency of DrmPipeline on crtcs by moving
the pending state of outputs from the drm objects to DrmPipeline itself,
which ensures that it's independent from the set of drm objects currently
used. It also changes requests from KScreen to be applied truly atomically.
The GlStrictBinding flag indicates whether it's okay not to re-bind the X11
pixmap to the OpenGL surface texture if the corresponding window is damaged.
It doesn't really affect the SceneOpenGL, only low level backend stuff.
This ensures that the window will have correct geometry if a maximized
window changes preferred decoration mode. X11Client does something
similar, see X11Client::updateShape().
In hindsight, perhaps, AbstractClient::{create,destroy}Decoration() must
preserve the old frame geometry, but it's not clear how to do that
because it requires decoration updates to be truly async, otherwise
there will be ugly flickering.
Currently, the scene owns the renderer, which puts more
responsibilities on the scene other than painting windows and it also
puts some limitations on what we can do, for example, there can be only
one scene, etc.
This change decouples the scene and the renderer so the scene is more
swappable.
Scenes are no longer implemented as plugins because opengl backend
and scene creation needs to be wrapped in opengl safety points. We
could still create the render backend and then go through the list
of scene plugins, but accessing concrete scene implementation is
much much simpler. Besides that, having scenes implemented as plugins
is not worthwhile because there are only two scenes and each contributes
very small amount of binary size. On the other hand, we still need to
take into account how many times kwin accesses the hard drive to load
plugins in order to function as expected.
This allows using base opengl backends in libkwin, which can be useful
later on for the purpose of moving the ownership of render backends from
the Scene class to the Compositor class.