Instead of best-guessing, at BGR (which in retrospect was a bad guess),
offer whatever resembles most the internal representation. This way the
frame gets to be least treated as it goes into the client.
...before releasing the connection!
this was randomly causing crashes because of use-after-disconnect
problems. since we would tear down the connection in ~X11WindowedBackend
but outputs wouldn't get cleaned up until QObject children cleanup of
the X11WindowedBackend object (or more precisely the OutputBase). this
would then result in ~X11WindowedOutput accessing a backend connection
that had already been closed
to help debug this type of problem moving forward let's also reset the
connection to nullptr during destruction. it's kinda pointless but it
makes it easier to spot use-after-disconnect
BUG: 466183
This reverts commit 4b1ef33c1e.
It introduced a crash. The large icons task switcher can create and
destroy the shadow in the middle of painting. When a shadow is
destroyed, kwin can make opengl context current. It will reset current
QOpenGLContext, and QtQuick can crash.
BUG: 466279
The input events can be processed when the workspace is not available,
e.g. during startup or shutdown, so add a corresponding guard.
As a long term plan, we need to decouple Workspace from low-level input
backend parts, but it will be a too invasive change for now.
BUG: 449317
BUG: 465456
Checking if the pointer needs to be confined before doing `std::clamp` on
the position is useless and causes problems. With this change, the pointer
will always be confined to exactly the screen, without any fractional offsets.
BUG: 461911
Currently the Shadow class is scene specific, which adds coupling
between Window and scene bits.
This change introduces ShadowTextureProvider that contains scene
specific stuff so the Shadow acts like a data source and is not coupled
to concrete scene.
It's gone in KF6
It's only used to obtain the install location of the package and resolve files relative to that
Use QStandardPaths to locate those files directly
Aurorae uses a QQuickWindow that receives an implicit scale through the
QPA. Unfortunately there's a known quirk with device pixel ratio not
being followed when offscreen surfaces are never shown and an
independent render control is used.
Without this QQuickRenderControl::grab ends up using a buffer the size
of the window * dpr, but with the contents rendered at 1x in the corner
along with incorrect device pixel ratio information.
This patch copies a used solution from EffectQuickView. This can be
resolved more neatly with newer Qt.
BUG: 452730
BUG: 465790
Since normal geometry is now rounded, we need to make sure to round
anything that should match that geometry, otherwise we risk things
peeking out of the normal geometry.
BUG: 464526
Before this commit, the device pixel ratio of the cursor was set to ignore
the Xwayland scale override, while the size of the cursor surface was scaled.
This change removes the scaling of the cursor surface size, to make the cursor
be no longer cut off in rendering.
BUG: 466094
Converting to wl_fixed is lossy. Especially for non-round values like 1.15.
This causes various visual glitches and off sizes.
Given we're using units of 120ths for the fractional scale protocol it makes sense
to fix the passed values for anything else over the wayland protocol.
BUG: 465850
Testing done:
ran a 1920 screen at 1.15 scale, got a logical size of 1670 which matches what it should be
The only one that does it differently is the DRM backend and it's just
an extension that takes GBM into account, otherwise it's effectively
copy-pasted code.
We need to register data types such as QVector<KWin::VirtualDesktop *>
both for QML and JavaScript scripts.
If you have no JavaScript scripts enabled, those container types won't
be registered and QML will fail to read properties such as
Window.desktops, which can result in already visible windows animating
opacity from 0 to 1 when opening overview effect.
To fix that, register all accessible data types in scripting apis in
Scripting::init().
We want floating tiles to be activatable, but also dismiss the effect by
clicking on the whitespace.
The current solution doesn't work as a floating tile that is in turn
split will pull focus from the children meaning those tiles can't be deleted.
Rather than special casing and z-manipulation we can simplify everything
by moving tile dismissal to the root of the effect and appropariately
propagating the event.
BUG: 465740
there is no practical reason I can see for why this should be limited to
stderr only. we are not reading or otherwise consuming stdout, we should
just pass it on.
Context: If a display is removed, the corresponding TileManager is removed with it. This in turn removes every one of its Tiles with it, and when a Tile's destructor is called, it attempts to find a new replacement tile for any windows it was previously managing.
However, if the Tile is removed because its corresponding TileManager has been removed, this has the potential to cause a segfault in KWin, causing it to crash (I suspect a possible race condition? but not sure).
This MR correctly evacuates custom tiled windows & migrates quick tiled windows upon output removal.
BUG: 465522
dmabuf buffers have the origin in the top left corner, so a texture with
attached dmabuf must have y inverted.
By correctly specifying the y inverted flag, we could leverage existing
infrastructure in kwin to handle vertically mirrored textures and make
simpler some projection matrix code in screencasting.
Even though the names seem to match, QtWayland maps button values
to enum values in ascendung order (as it does on X11). The wrong
mapping is usually not a problem because we send the native button
events to clients. However when the Qt names or values are used
for communication between KWin and a client this leads to
misunderstandings.
BUG:465463
FIXED-IN:5.27.1
This isn't necessary with atomic modesetting, as moving and setting are
the same thing. With legacy though, if the cursor was hidden, moving it
with the layer visible does not automatically show it again, so that needs
to be done explicitly
BUG: 461181
This has the benefit of providing a saner default for the values
of `opacityActive` and `opacityInactive` rule properties, both
in the UI and when reading the config.
The side effect is the same we have when changing default values:
if someone would have set a rule with some opacity to 0%, it will
be read as 100% next time kwin starts.
In this case it is a small price, as it is always easier to change
it back when the windows are visible that restoring it when they're
not, specially if it wasn't voluntary.
Once upon a time, in a moment of acute stupidity, I accidentally created a window rule making all windows completely transparent. I meant to go for 0% transparency when really the slider said 0% opacity. And once you've made the very window to change this setting invisible, the only way to fix that mistake is to log into a TTY or different DE and find the config file to edit manually. Since I've since seen several KRedditors fall into the same trap:
Show a warning when active or inactive opacity is set to ~~<= 15%~~ < 25%.
![warning](/uploads/0b1178bf5782bff3b4293a0031bb4fca/warning.png)
PointerInterface is a "Server-managed multicasting resource". As in we
have one QObject, managed by the server, but internally it represents
multiple resources from various clients.
We cannot control the lifespan of those resources, they may persist long
after we stop having these capabilities on the seat.
If we delete our pointer object when we stop advertising a pointer
capability we have race conditions with clients calling release, or
potentially even having a seat_get_pointer in flight.
It's easier and safer just to have PointerInterface last as long as the
Seat. If we don't have a mouse no-one should try to bind, and even if
they did or remained bound long after we stop having a mouse it won't do
any harm as there are no mouse events to broadcast.
QAbstractEventDispatcher blocks and waits constantly on every external event
processed; every timer or update from an X or wayland client, mouse
move or DRM event.
Right now every time this happens we go and check Xwayland for new
events, this is a system call (poll) that based on strace will
unsurprisingly immediately return with EAGAIN as there's nothing to read
from X. If there is something to read our socket notifier will fire. On block we do still need to read any events read in the meantime that weren't dispatched.
This cuts down our system calls significantly, which hopefully should have a
noticeable impact on performance especially when the kernel is under
load.
---
Found whilst analysing strace (by accident whilst looking for something else!)
In a simple case of xwayland nested running glxgears we go from 28 calls per frame to 21. With many many clients and more input events it'll be an even higher percentage.
The current state is inconsistent. Some window-specific signals are
exposed in the workspace, some not.
This change drops those signals. One should monitor the signals it's
interested in instead.
The blur effect is used to improve the contrast. The option was added
thinking "why not? it might be useful." This was perhaps a mistake and
it should have been added with a clear valid usecase in mind.
CCBUG: 457495
Leverage the standardized ShortcutSettings config object to handle
the shortcuts config for the tabox (setting default values, reading
and saving to KGlobalAccel, etc).
This way, we can remove the extra methods in TabBoxConfigForm and
improve separation between UI and logic.
It also fixes the actions getting stored untranslated when saving
from the KCM (until next restart of KWin)
Provide a new KConfigSkeleton (ShortcutSettings) so that the
KCModuleData knows if any of the shortcuts is non-default.
This improves the UX by showing an "orange dot" in system
settings when just a shorcut has been changed.
We also need to implement a new specific KConfigSkeletonItem
(`ShortcutItem`) that uses KGlobalAccel to retrieve and store
the shortcuts, instead of storing them in a config file.
This installs a socket notifier onto our xwayland socket, when a user
connects we launch xwayland. The client then connections once kwin has
established itself as the compositor.
For a full desktop plasma session this patch effectively does nothing
too useful as we still start kcminit and make xrdb calls on startup
which in turn will launch X, but for the same reason this patch should
be harmless now as we're still processing the xrdb calls before any
clients will connect.
By passing the config object to the TabBoxConfigurationForm, we
can handle it directly instead of bouncing information from and
back between the forms and the KCM main class.
Now the user changes in the UI translate to the config objects,
which can directly provide `isSaveNeeded()` and `isDefaults()` info.
This allows to simplify the logic on both classes, reducing the
coupling between them and minimizing the number of exposed public
methods and some boilerplate.
If the window has been originally on another output, make sure that the
window will be properly put back on it.
This logic seem to originate from 7d67380205,
but it's not necessary anymore because geometry restore will be updated
if the window is moved to another output by the user.
BUG: 465358
- Add the switchers to the model directly, instead of using
temporal lists and a second loop over them
- Use the same model for main and alternative forms
This makes this code a little more clear and efficient
When a window goes away it was stoppping translucencyWindowTypeAnimation
and translucencyInactiveAnimation but any translucencyMoveResizeAnimations
was hanging there forever, causing ghost windows
BUG:439332
If a window is made ready for painting with some delay, the item won't
schedule an update. To fix that, sync the item visibility state with
Window::readyForPainting(). When the item visibility changes, a repaint
will be scheduled.
BUG: 464955
Window::maximize() used to be split in two halves:
- generic Window::setMaximized() and Window::maximize()
- protocol-specific Window::changeMaximize()
Window::changeMaximize() used to block all geometry updates and
Window::maximize() emit "maximize mode changed" signals. With that,
frameGeometryChanged came always before clientMaximizedStateChanged.
After merging Window::changeMaximize() and Window::maximize(), the order
of the signals has been reversed because of RAII. Unblock geometry
updates explicitly to preserve the old behavior.
BUG: 465157
Imports come at a big cost when they're unused.
Also we shouldn't be importing WindowView from a different plugin. If
that effect is disabled it meant tileseditor would fail to load.
BUG: 464970
This affects direct scanout and when the window isn't triggering desktop
repaints otherwise, like being minimized or on a different virtual desktop
or activity
KDecoration.Decoration eats all the events for the sake of keeping
an illusion of buttons being like the real ones. I didn't find any sane
way to completely turn off event filtering on that level, so instead
let's fix this MouseArea, which is a workaround, but a decent one.
AFAIK this is the last KCM in Plasma to properly support "double-click
to save" behavior. There might be others though: watch out for event
filters inside thumbnail.
If the root tile node contains only one child node, but the child node
has its own children, kwin will fail to show an outline when the user
interactively tiles the window.
On the other hand, there is no reason to have this child count check.
For what it's worth, it also prevents tiling the window if the output
only has one tile, which is odd, but a valid usecase.
BUG: 464379
Normal event flow is from a client view is
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
or
wlr_data_control_source.cancelled
wlr_data_control_device.selection
However when the race mentioned in the comment happens the client
sees
-> wlr_data_control_device.set_selection
wlr_data_control_device.selection
wlr_data_control_source_cancelled
Which can confuse client state thinking the clipboard didn't change
as it associates the selection event with its own request. Resend
the selection event in this case to tell the client the correct
selection.
BUG:464509
FIXED-IN:5.27