Otherwise, the pipeline state from an earlier hotplug scenario can leave
the pipeline disabled and without a CRTC, which means leasing the output
will fail
BUG: 487938
FIXED-IN: 6.1.0
If the mode the user has previously set through KScreen isn't available, this falls
back to a different mode without overwriting the user preference. If on the next
hotplug, the desired mode is available again, it then gets chosen instead of the
fallback
BUG: 484037
As per the docs:
Note: This function does not need to be, and must not be, called when
using the software adaptation of Qt Quick.
This sets up RHI on the render control, which in turn sets RHI on the
window, which shouldn't exist when using software rendering.
BUG: 482663
BUG: 486078
A layer shell window can request a screen edge without having a chance
to map the surface. In that case, no Workspace::windowRemoved() signal
is not going to be emitted because no surface has been mapped. Perhaps
it needs some re-wiring, but on the other hand, it is also more reasonable
to monitor Window::closed() signal.
With this change, the ScreenEdges manager will reject any request to
reserve a screen edge for a closed window. And in addition to that,
the ScreenEdges will unreserve screen edges when the window is closed
rather than when the window is unmapped.
CCBUG: 485318
Whilst the XWayland input filter only runs whilst XWayland is running
there is hypothetical window between the wayland connection to xwayland
being disconnected and handleXwaylandFinished, the process exiting. This
should be guarded correctly.
BUG: 480925
If a new drag and drop session is started while there is already one
existing, it's possible to end up in a situation where the
SeatInterface::dragEnded signal is emitted the second time when one of
the data sources is destroyed.
CCBUG: 460374
HiddenPreviews was a hack to not inform X11 that windows were minimised,
so that their previews kept working.
On wayland the user facing setting is not visible but the value is
loaded which is a bad combination.
CCBUG: 415286
Write something into the logs when a call goes awry, it can save some
time to the next person porting kwin to a dysfunctional driver.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
05a3e2bad9 added `geteuid` use but didn't
add the needed headers. This works by chance on libstdc++ systems via
transitive includes, but it doesn't work on libc++ systems, as reported
downstream in Gentoo at https://bugs.gentoo.org/933120.
The Qt pipeline cache causes a disk sync on every load and save of a
QQuickWindow. This causes a stutter under high disk usage.
The gains from this cache are minimal on our simple scenes on PC
hardware. Especially given mesa has it's own cache, profiling on my
personal laptop showed the pipeline as being 0ms.
There is an upstream patch at
https://codereview.qt-project.org/c/qt/qtdeclarative/+/564411 .
QSaveFile still has a sync, but that should only be hit for the first
non-cached run. I'm also adding a flag to QSaveFile to fix the QML cache
and first run case.
Tested via running kwin with `strace -e
inject=fdatasync:delay_enter=10000000` to simulate a slow flush.
BUG: 487043
Fullscreen effects typically will show all the windows, when the effect
ends having the windows disappear doesn't really work.
From a user point of view any full screen effect is a new task, we want
to cancel any preivous task.
BUG: 487299
Until effects are converted to schedule repaints on the item they're modifying,
we need to allow repaint scheduling from nullptr items, and handle repaints on
the (cursor) render layers to still be filtered out
BUG: 487480
This will also look at the "product serial string" in addition
to the actual serial number. The former is what we use elsewhere
in Plasma like the kscreen kcm.
BUG:485015
FIXED-IN:6.1
QOpenGLContextPrivate::setCurrentContext() was dropped because the
platform opengl context no longer uses QOpenGLFramebufferObject, which
needed QOpenGLContext::currentContext().
When the render time estimation is much higher than the real render time, and triple buffering is
enabled, the previous logic would schedule frames multiple vblanks in advance, which could drop the
effective refresh rate by more than is necessary. This commit limits it to the second vblank after
the current time, which ensures that we hit the full refresh rate even when render time prediction
is wrong
Otherwise, if render time prediction and actual render time are very different,
a lot of frames get dropped and in some cases more frames than is useful are
rendered, creating stutter instead of only unnecessary latency
BUG: 487605
