kglobalacceld needs to process all key events to detect whether
a modifier only shortcut has been triggered.
On the other hand, when using Meta+Space keyboard layout switching
shortcut, we will get the following key syms (not native scan codes)
- press meta: Meta_L
- press spacebar: Super_L
- release meta: Meta_L
- release spacebar: Space
The fact that xkb reports Super_L when the spacebar is pressed trips
modifier only shortcut detection in kglobalacceld, and it's likely
that kickoff will open after pressing Meta+Space to switch the keyboard
layout.
In order to prevent that, kglobalacceld needs to see all key events
even with invalid key codes. As an alternative, we could explore the
possibility of using native scan codes instead of mapping keysyms to
key codes, but that needs thorough analysis, which we have no time
for.
The check was introduced in 4403e86acc.
After that check is removed, the test still passes.
This is the backend that will be used by the portal to enable
the functionality of the input capture portal.
When the cursor tries to move out of the workarea across a barrier
that the portal registered all input events are filtered out
and forwarded via eis.
The cube effect has a placeholder which can update the delegate at
runtime. There's an "add desktop" button which then might give us 3
virtual desktops. As a general rule any setter exposed via a declarative
API should always perform the setting.
Reloading has to be delayed because otherwise we unload the caller.
BUG: 486839
With this change the preferred buffer scale, transform and color
description properties will be latched to xdg shell configure events.
This should ensure that the clients are told the preferred buffer
scale before the first configure events.
This makes it a bit more conservative for reducing latency, which decreases the
amount of dropped frames in desktop usage a lot (by 13x on my desktop, 2x on my laptop)
pointerEvents contain all motion events, the xwayland filter is only
concerned with forwarding clicks. Right now we would update an invalid
button state constantly. It did nothing harmful but was still a bit
silly.
An EDID can contain zero or more detailed timing definitions, which can contain
more precise physical dimensions of the screen (in millimeters, as opposed to
centimeters).
The Xorg server has similar logic for determining the physical screen size from
the EDID: pick the first sane size from the detailed timing definitions, and
fall back to the screen size given in the "Basic Display Parameters & Features"
section.
BUG: 486585
Apparently people have differing ideas of what "vertically" and
"horizontally" mean, and some feel that this wording contradicts the
icon.
That's not accurate, but the wording is admittedly a little a bit
ambiguous. We can clarify this by using super duper explicit
terminology that always matches the icon.
BUG: 475103
FIXED-IN: 6.1
If the slow transition is scheduled slightly earlier before m_next.first,
don't skip the "m_prev.first <= todayNow && todayNow <= m_prev.second" branch.
Also explicitly handle the case when resetSlowUpdateTimers() gets called
after m_prev.second, i.e. the previous transition has finished running.
Due to QTimer sometimes firing a tad bit early, transitions get skipped, or we
end up in the "Error in time calculation" branch. This commit improves timer
handling to avoid this.
We do not snap to docks (i.e. panels) since the ones we
actually want to snap to (i.e. always visible ones) will
restrict the workspace area, and the window will snap to
that, effectively snapping to the panel too. Explicitedly
avoiding panel snapping solves any possible issue of
floating panels, since they change their size when a window
gets near them.
The communication between the compositor and plasmashell is asynchronous.
It's possible that plasma can call get_window_by_uuid before it is notified
that the window has been closed. There's no any way around with the
current design of the protocol. So printing a warning message is
unjustified. This fixes kwin's logs being full of "could not find window"
warning messages.
After receiving a drop a client should call data_offer.finish
to tell the source it's done using the drop.
A client could delete an offer after drop before calling finish.
This can happen with misbehaving/buggy or malicious Wayland clients.
A real case was found in the wild with Chromium, as described in the
linked bug.
In this situation we should let the source know the dnd is finished
as there are no other transfers than can take place.
We don't want to universally send this in all data offer destructors
only, offers that are deleted post drop so the flag on the source is
exposed.
BUG: 482142
Currently, the dmabuf format is hardcoded to DRM_FORMAT_ARGB8888, but
testCreateDmabuf() uses m_drmFormat.
Furthermore, if the shm buffers are used, it's preferred to use a buffer
format that's friendly to QImage and OpenGL, which is DRM_FORMAT_ARGB8888.
It appears like pipewire can ask kwin to allocate a drm buffer even
though m_dmabufParams has been reset. It's underspecified when pipewire
will start requesting new buffers after changing the stream params. So
use the last reported video info to allocate buffers. If even it is wrong,
then it's an issue somewhere in pipewire.
Right now the opening duration is 150ms, and the closing duration is
250ms. Neither are standard durations we use elsewhere, and it's also a
bit odd to be slower to close than to open--at least from a visual
perspective.
The average of these value happens to be 200ms, which happily is the
exact value of Kirigami.Units.longDuration.
As such, use that value instead, in the interests of visual consistency.
Enabling this feature makes Xwayland send xtest events via
the remote desktop portal and libei.
XWayland will create a new session for each X client (it keeps
contexts around and reuses them if the cmdline matches, so not
every xdotool invocation produces a new portal prompt).
n_datas must match the plane count in the graphics buffer. But apparently
pw buffers with wrong n_datas can still slip through somehow. It makes
the screen cast stream crash when filling in buffer data.
The crash is hard to reproduce, but on the other hand, according to
sentry, a substantial number of users is affected by this issue.
Taking the defensive approach is not great, there will likely be other
issues with screencasting, but it seems like the only feasible option
so far. Broken streams is better than kwin crashing. It also wouldn't
hurt to add some warning messages, that will be done in a follow up MR.
Vlad Zahorodnii
David Edmundson
David Redondo
l10n daemon script
Xaver Hugl
Jakub Piecuch
Nate Graham
Volodymyr Zolotopupov
Ambareesh Balaji
Niccolò Venerandi
Pau López