When running in plasma, the animation speed slider is in General
Behavior KCM.
The Defaults button should not reset the animation speed slider because
it's hidden.
BUG: 442600
With per-screen rendering, the projection matrix is no longer created
with the workspace geometry, i.e. all screen geometries united, so the
center of the workspace geometry may not map to (0, 0) in the clip
coordinates.
GLRenderTarget::virtualScreenGeometry() can be used to query the rect
that was used to create the projection matrix.
BUG: 442770
KMS can only ever have one frame pending at the moment. If we
update the outputs while a pageflip is still pending on any output
the atomic commit will fail with EBUSY, which both invalidates
the testing for output configuration and makes applying the wanted
configuration fail.
This can be removed again once KMS gains the ability to do mailbox
presentation; that will likely still take a while though.
BUG: 442677
Currently, data from client buffer EGLStream is copied to a surface
texture. An fbo is used for that purpose. The main issue with it is that
it doesn't restore the old framebuffer binding.
The surface texture can be updated in the middle of a compositing cycle.
If the framebuffer binding is not restored, any window that must be
rendered in an offscreen texture won't be rendered to the offscreen
texture.
This change makes EglStreamSurfaceTextureWayland restore the fbo binding
so the DeformEffect and software screen rotation work as expected with
the proprietary NVIDIA driver.
BUG: 442697
This makes the compositingPossible() output more elaborative,
and adjusts their priorities to qCWarning.
I thought about dropping the "Compositing is not possible"
(qCCritical) message. It's not critical for X11 and Wayland
depends on OpenGL. OTOH it's from a different component. So in
the end I settled for qCWarning again; there is no real way
to know, if the platform will consider this a critical problem
(and eventually abort).
Then I saw X11StandalonePlatform::compositingNotPossibleReason,
which has more user friendly, QT Richtext / HTML encoded output,
but this seems overkill for the terminal; now I would like to
know, where this is actually used...
While at it report "manually" suspended compositing via qCInfo
instead of qCDebug.
After updating my Debian buster to bullseye, I noticed missing
shadows / composite for KDE, which made overlapping windows hard
to recognize.
.xsession-errors just had "kwin_core: Compositing is not possible".
Using the suggested QT_LOGGING_RULES="kwin_*.debug=true" didn't
provide any more clues; nothing I tried did.
Eventually I ended reading the kwin source and found, that
disabled composite via kwinrc :: [Compositing] :: OpenGLIsUnsafe
was not reported.
IMHO all these disabling cases should use qCCritical(KWIN_CORE),
like the "Compositing is not possible" message, but for the time
being, this simply logs the OpenGLIsUnsafe reason, just like all
the others.
With the recent AbstractOutput changes, Workspace::clientArea() overload
that takes only the window and no additional output was changed to
return clientArea(opt, window, window->output());
prior to that, it had been looking up the output at the center of the
frame geometry.
As it turns out, AbstractOutput::sendToOutput() blocks geometry updates,
which in its turn means that Toplevel::output() will be updated only
after geometry updates are unblocked. For the most part, it's not a big
deal until you need to use Workspace::clientArea(opt, const Toplevel*)
Since the output won't be updated until geometry updates are unblocked,
clientArea(opt, const Toplevel *) may return outdated info.
One could argue that we just simply need to update m_output similar to
m_frameGeometry when geometry updates are blocked, but... it's not going
to work on wayland! On Wayland, GeometryUpdatesBlocker is totally
unnecessary. Even if a window is resized, m_frameGeometry will be left
unchanged until the client repaints the window.
Instead, one need to pass the AbstractOutput to clientArea() if it's
important.
This change makes X11Client::changeMaximize() query the MaximizeArea of
the output containing the center of the move resize geometry, similar to
what the XdgToplevelClient does.
BUG: 442534
There are some unresolved issues where driving outputs can fail because
of bandwidth constraints. These don't appear to happen with implicit
modifiers, or at least they don't happen as often.
libinput will send release and proximity out events after the device is
disconnected.
This just takes into account that tablet might be nullptr.
BUG: 442573
The stored geometry is irrelevant in the window is maximized.
This is especially relevant if we:
* open a virtual keyboard
* rotate the display (then it looks ok as it was already addressed)
* then remove the keyboard.
At that point we want to reset to the available area rather than the
previous.
By supporting all the required attributes in the DecorationThemeMetaData class
the custom struct can be dropped.
Task: https://phabricator.kde.org/T14744
We can just put the parameter in the variant list. Because the method is virtual, the keyword
parameter must exist in the method definition.
Task: https://phabricator.kde.org/T14744
b38bb416 introduced flicker when restarting compositing because the
DrmGpu::findWorkingCombination method usually creates new buffers for
the commit, without rendering into them. Instead of that, re-use
existing buffers where possible
The configs returned by eglChooseConfig are sorted from highest to lowest buffer sizes.
Filter the configs to find a suitable candidate that matches the requested attributes of the surface.
This fixes the corrupted Aurorae window decorations on Wayland with the proprietary Nvidia driver.
Conceptually, a configure event inherits its parent's state and adds
some of its own. This allows the compositor to skip intermediate
configure events in ack_configure handler and jump to the last one.
Currently, the only field that XdgSurfaceConfigure objects need to
inherit is flags. The geometry info and window states are filled in by
role commit implementations to their latest values.
XdgSurfaceConfigure::flags indicates if the configure event moves the
window. This flag is important to resolve conflicts between geometry
updates initiated by the user and the ones that are made in response to
acknowledged configure events, e.g. after maximizing the window, etc.
(effectively, if the user moves a window, kwin will cancel scheduled
moves in configure events)
If configure flags are not inherited, we can end up with the following
case:
* configure event A (flags: {position})
* configure event B (flags: {})
If the client acknowledges configure event B, kwin will skip configure
event A, and thus it won't move the window to the right place. This is
the root cause of fullscreen mode misbehaving with apps such as google
chrome.
discardPixmap() increases the reference counter, but there's no matching
place where the ref count is decreased, which results in the previous
pixmap not being released even if it's not needed anymore.
Instead of setting pipelines one by one, use DrmGpu::updateOutputs to
set all the outputs on a GPU with a single atomic commit. This makes
the switch both faster, more reliable and in case the other drm master
changes the output configuration, prevents blanking.
eglCreateWindowSurface() wants a Window (unsigned long), but with
EGL_NO_PLATFORM_SPECIFIC_TYPES, EGLNativeWindowType is defined as an
opaque pointer, i.e. void*.
BUG: 440372
If a property blob got created by another drm master we can't rely on
re-using it, so create a new blob of our own with the data copied over
when the kernel destroys it.
Also free property blob objects when we don't need them anymore.
BUG: 440294
