At the moment, the desktop layout in _NET_DESKTOP_LAYOUT overwrites new
desktop layout with outdated information. This happens because kwin tries
to honor the desktop layout set by the pager. However, kwin itself
already acts as the pager. The pager applet in plasma doesn't attempt to
maintain _NET_DESKTOP_LAYOUT with proper values.
On the other hand, kwin trying to both update and also sync its state to
_NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES has created a series of
issues, like lockups or rendering glitches.
Given that the window manager can ignore these properties, and the fact
that kwin already does act like a pager, this patch makes kwin ignore
external updates to _NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES.
In order to modify the desktop layout on X11, use the dbus api. On
Wayland, either the dbus api or the virtual desktop wayland protocol.
BUG: 422319
BUG: 480371
Support is hidden by an environment variable to prevent accidental standardization
on this experimental version. It allows app devs to already implement and
test it though, and easily switch to the proper protocol later
A window is added to the workspace when it's mapped. It's assumed that
the first Window::windowShown signal indicates that. But it's not
entirely true. For example, if setHidden(false); setHidden(true); are
called in succession, the window will be marked as ready for painting
even though it isn't.
The Window::readyForPaintingChanged() signal fixes that. It's emitted
when the window is actually mapped.
At the moment, if the workspace extends or shrinks by an output, the
hidden panel will be shown. It doesn't make sense in all cases.
Furthermore, no screen edge will be reserved if the layer surface has
some margins.
To address that, allow "floating" panels reserve screen edges and also
make kwin try harder to preserve window edges if the output layout
changes.
CCBUG: 448420
It seems like QWindow::setGeometry() won't update the associated output
if no platform window has been created, which is the case when running
overview or any other qml effect.
It's not clear whether this is a Qt bug or intended behavior.
qwindow.cpp contains comments assuming that the window is on the primary
output if no platform window exists.
QQuickWindow::effectiveDevicePixelRatio() uses the device pixel ratio
of the attached QQuickRenderTarget. Instead, the scale factor of the
output should be used, which is what QWindow::devicePixelRatio() returns.
By default the focus item in a tabbox is always the main item, so if the
main item is not a focus scope, the inner item will not get focused.
BUG: 477286
FIXED-IN: 6.0
This can be used to disambiguate the exclusive edge when the anchors are
on a corner (so there would be 2 candidates)
it's quite quick and dirty mostly to understand if we do want to push for
something along the lines (it should at least do a protocol error when
the requested edge is not within the anchors)
If the active window is on a different output than the one the renderloop is for,
the scheduling logic would otherwise never schedule a repaint while adaptive sync
is active.
BUG: 480252
It's universally supported, and our format negotiation code needs improvements to
properly handle the receiving application not suporting the actual output format
`QRegion::operator|=` has some optimizations but it basically boils
down to
QRegion result(*this);
result.detach(); // it will make a copy because this is shared
result.d->append(rect);
return result;
On the other hand, `QRegion::operator+=` tries to add the new rect
in-place.
Currently, if only blur behind decoration is enabled, no m_windows entry
is going to be created and so the blur effect won't blur the background.
BUG: 479893
Currently the window rule is not 100% effective because the "take focus"
message is not guarded. So depending on the input model of the X11
window, kwin can still activate a window even if it has a window rule
to force no focus.
workspace()->setShouldGetFocus() should be guarded too to help the focus
stealing prevention logic.
Technically though, forcing XSetInputFocus() or WM_TAKE_FOCUS if the
client doesn't advertise supporting them is finiky. But on the other
hand, the window rules are an advanced feature, so its assumed that the
user knows what they do.
The output goes through the following stages when it changes its dpms
mode:
- Output::aboutToTurnOff()]
- some time later, Output::dpmsModeChanged() to indicate that it's off
- Output::dpmsModeChanged() to indicate that it's back on
- Output::wakeUp()
The Output::dpmsModeChanged() signals in the middle are optional. They
may not be emitted after Output::aboutToTurnOff() if the user quickly
cancels the dpms mode transition.
The Workspace should monitor the Output::wakeUp() signal instead.
Alternatively, create the dpms input event filter only after the dpms
mode has changed. While the screen won't be turned back on immediately,
it's still going to produce acceptable visuals. Either solution is fine.
This patch makes the Workspace monitor the wakeUp signal because it
takes fewer lines of code.
BUG: 479659
The compiler prints the following warning at the moment:
wl-socket.c:143:9: note: ‘snprintf’ output between 10 and 20 bytes into a destination of size 16
When edid parsing fails, KWin will base output settings on the connector, which
isn't great on its own, but at least works in many cases. When the edid can be
parsed later though, the display settings will reset because now the edid identifier
is used to exclude the old config (in which the latter is missing).
To work around that, this commit adds output identification based on the edid hash,
which is also not ideal, but can be safely matched with in case no output config
with a matching edid identifier exists.
This optimizes out an unnecessary atomic test - instead of testing the new state and
then attempting to present with that new state, this just directly tries to present the
full state. If that commit fails, the backend just tries again with the safer presentation
mode.
