Summary:
The NVIDIA implementation of glXSwapBuffers will, by default, queue up
to two frames for presentation before blocking. KWin's compositor,
however, assumes that calls to glXSwapBuffers will always block until
the next vblank when rendering double buffered. This assumption isn't
valid, as glXSwapBuffers is specified as being an implicit glFlush,
not an implicit glFinish, and so it isn't required to block. When this
assumption is violated, KWin's frame timing logic will
break. Specifically, there will be extraneous calls to
setCompositeTimer with a waitTime of 0 after the non-blocking buffer
swaps, dramatically reducing desktop responsiveness. To remedy this,
a call to glXWaitGL was added by Thomas Luebking after glXSwapBuffers
in 2015 (see bug 346275, commit
8bea96d701). That glXWaitGL call is
equivalent to a glFinish call in direct rendering, so it was a good
way to make glXSwapBuffers behave as though it implied a glFinish
call.
However, the NVIDIA driver will by default do a busy wait in glFinish,
for reduced latency. Therefore that change dramatically increased CPU
usage. GL_YIELD can be set to USLEEP (case insensitive) to change
the behavior and use usleep instead. When using the NVIDIA driver,
KWin will disable vsync entirely if GL_YIELD isn't set to USLEEP
(case sensitive, a bug in KWin).
However, the NVIDIA driver supports another environment variable,
__GL_MaxFramesAllowed, which can be used to control how many frames
may be queued by glXSwapBuffers. If this is set to 1 the function
will always block until retrace, in line with KWin's expectations.
This allows the now-unnecessary call to glXWaitGL to be removed along
with the logic to conditionally disable vsync, providing a better
experience on NVIDIA hardware.
Reviewers: #kwin, davidedmundson, zzag
Reviewed By: #kwin, davidedmundson, zzag
Subscribers: kwin, davidedmundson, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19867
Summary:
When Compositor finishes compositing, it destroys EffectsHandlerImpl,
which in its turn tries to unload all effects. But there is a problem...
EffectsHandlerImpl has platform-specific hooks to ungrab keyboard and
also stop mouse interception. Given that any call made to a virtual function
in the destructor of a base class(EffectsHandlerImpl) won't go to a derived
class(EffectsHandlerImplX11), keyboard won't be ungrabbed even if effect
that grabbed it is already gone.
BUG: 399572
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19178
Summary:
On Wayland we cannot switch from OpenGL to QPainter compositor as this
would break any running OpenGL application. KWin registers it's
EGLDisplay to Wayland and without OpenGL this doesn't make sense any
more. We are not able to render OpenGL buffers in the QPainter
compositor.
While it's theoretically possible to switch from QPainter to OpenGL it
doesn't make any sense for the same reason. Any running OpenGL
application would be using llvmpipe and could not be switched to proper
OpenGL.
This change stores the selected compositing type in Platform and the
implementations can use it to restrict the supported compositors. On X11
we don't need this, all other Platforms implement the restriction. Thus
it's no longer possible to switch the backends at runtime.
Test Plan:
Adjusted tests run, no runtime test as gui doesn't support
switching to QPainter anyway.
Reviewers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19084
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
Mesa requires XESetWireToEvent xlib callbacks to be called
when DRI2 is used. This is done by the GLX integration in
the Qt's xcb plugin, but Qt 5.12 initializes the GLX integration
only when required, e.g. when a window with OpenGL support is
created or when availability of OpenGL is checked.
So force initialization of the GLX integration by calling
QOpenGLContext::supportsThreadedOpenGL().
https://codereview.qt-project.org/#/c/6557/https://bugzilla.opensuse.org/show_bug.cgi?id=1120090
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, graesslin, fvogt, filipf, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18366
Summary:
This ensures that KWin gets the same keyboard layout config as is
configured in the session and not a default config.
BUG: 402764
FIXED-IN: 5.14.5
Test Plan:
Xephyr to verify the config is applied, otherwise completely
untested. I don't have an X session.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17967
Summary:
This change inits XInput extension, listens for touch events and
forwards them to our platform API. Thus touch events are forwarded on a
nested wayland session on X11.
Please note that I only tested this change on Xwayland.
Test Plan: Run nested kwin_wayland with two outputs and looked into debug console
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17369
Summary:
This brings KWin a step closer to be run from build dir without having
to install at all. The integration tests are adjusted so that the
virtual platform is still found which makes the code be closer to what
is used in normal kwin_wayland.
Test Plan: ctest passes, manually verified correct plugin is loaded
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17388
Test Plan:
Ran kwin_wayland --windowed --scale2
Hovered over deco. Got massive and detailed cursor
Hovered over a wayland client (Qt 5.11 not dev)
Got a massive, but slightly blocky cursor
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13642
Summary:
Instead of seeing the cursor <--> on the left edge you now see an icon
that looks like |<- .
This brings kwin decorations in line with GTK CSD icons.
In theory this is also useful to tell which window will resize in the
case of side-by-side windows (regardless of whether borders are on or
not). In practice with the adwaita icon theme I tested with it's not
very intuitive to realise which is which till you learn the icon.
Change is more involved than it should be as Qt::CursorShape doesn't
have these entries, and I don't want to shadow that enum internally or
have
to change kwin effect code.
Specifics depend on cursor icon theme if they are not present it will
fallback to the <--> icon. (Breeze does not have them currently)
Test Plan:
Resized some windows (on X and on Wayland)
Correct icon appeared on Adwaita
Existing icon appeared on Breeze
Reviewers: #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13396
Summary:
The support for interactive point selection was missing. This results in
the ColorPicker dbus API always returning an error on X11. We either need
to disable the ColorPicker on X11 or add support for this functionality.
As the X11 platform basically supports selecting a point in the
interactive window selection it makes more sense to add this missing
method in the platform than to disable support of color picker effect.
BUG: 387720
FIXED-IN: 5.12.1
Test Plan:
Run KWin/X11 on Xephyr and was able to pick a color and
kill a window
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10302
Mesa's glXChooseFBConfig will not return any sRGB capable fbconfig when it
is not explicitly asked for. On some systems, the only ARGB32 visual is
paired with an sRGB capable fbconfig, so application windows using ARGB32
visuals would fail to display.
BUG: 387159
FIXED-IN: 5.11.4
Summary:
This is meant to address Bug 372114. The problem here is that the KConfig
object (and its derivatives), that the freeze detection thread needs to
record the freeze, are not thread safe. When it happens that the main
thread is in fact not frozen, it is possible that the two stomp on each
other's KConfig object.
The solution applied here is to use the KSharedConfig::openConfig
function, which is thread safe, on the freeze detection thread. As was
mentioned by Martin Flöser in the discussion, the thread needs to obey
the name of the main config file of KWin, which can change in the future.
As a secondary issue, this patch also turns off KCrash reporting for
aborts due to a freeze being detected. IMO it is not very user friendly
to still show a crash report to the user, even after this bug is fixed,
for the deliberate SIGABRT. Maybe a less intrusive notification could be
used to tell the user why effects are suddenly disabled?
I've been using kwin with this change for several weeks now and it makes
the restarts of kwin due to freezes unobtrusive. However, most (I would
say almost all) of these freezes are actually instances where the system
is being slow after eg. screen resolution is changed.
BUG: 372114
FIXED-IN: 5.11.3
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: ngraham, graesslin, anthonyfieroni, cfeck, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8356
Summary:
We want to translate by the monitor position, so that needs to be
the negative of the position.
But Kwin/KScreen treats 0 as the top of all monitors. GL treats 0 as
bottom, so that all needs inverting.
Hence this should be a positive y value for the viewport.
BUG: 386099
BUG: 385655
Test Plan:
Had two monitors
Side by side was - fine
Stacked vertically - still fine
Modded X code to extend in y instead of x.
3 monitors worked fine.
Nested wayland only seems to support one screen?
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8479
Summary:
On Wayland we have the sync disabled as it doesn't work properly. This
allows us to also move the sync event handling into the X11 standalone
platform.
The code is slightly refactored: instead of passing the event to each
Client, we search for the matching Client. For that the SyncAlaram struct
is added to public section of Client. The method to handle the sync
doesn't need the event any more and is moved from events.cpp to
client.cpp.
Test Plan:
Run Xephyr+kwin_x11, resized a window and verified through
gdb breakpoint that the sync still works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7942
Summary:
So far KWin does not know which Compositors the platform actually
supports. This results in KWin happily trying to use the OpenGL
compositor on fbdev or the QPainter compositor on hwcomposer although
that is obviously going to fail as the platform doesn't support this.
By adding a pure virtual method all Platforms can define what they
support. In a later step the Compositor can use this to create an
appropriate scene and also perform proper fallback handling in case the
scene creation fails.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8316
Summary:
The Platform API is extended by a call to create the EffectsHandler. In
X11 standalone Platform a new EffectsHandlerImplX11 is added which
contains the X11 only parts of the EffectsHandler, such as grabbing the
X keyboard and the X11 mouse interception window.
The EffectsHandlerImpl gains some virtual methods for the parts which
are now done in the X11 specific implementation. In return we get rid of
lots of if-else structures checking for the operation mode.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7955
Summary:
Unfortunately a rather large change which required more refactoring than
initially expected. The main problem was that some parts needed to go
into platformsupport so that the platform plugins can link them. Due to
the rather monolithic nature of scene_opengl.h a few changes were
required:
* SceneOpenGL::Texture -> SceneOpenGLTexture
* SceneOpenGL::TexturePrivate -> SceneOpenGLTexturePrivate
* texture based code into dedicated files
* SwapProfiler code into dedicated files
* SwapProfiler only used in x11 variants
* Safety checks for OpenGL scene moved into the new plugin
* signal declared in SceneOpenGL moved to Scene, so that we don't need
to include SceneOpenGL in composite
Test Plan: Nested OpenGL compositor works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7740
Summary:
A dedicated X11EventFilter is added and created from the X11Cursor in
case we have XFixes. This means some more X11 specific code is now only
on X11.
Test Plan: Only compile tested.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7843
Summary:
Only needed for kwin_x11 variant (required for the non-composited
Outline). As that's nowadays in the x11 platform, we can move the
complete XRenderUtils support into the platform. Thus KWin core does
no longer require to link it.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7760
No idea why the code compiles on my system. This change is based on the
output on build.kde.org.
CMakeFiles/testXRandRScreens.dir/__/plugins/platforms/x11/standalone/screens_xrandr.cpp.o:
In function `KWin::XRandRScreens::event(xcb_generic_event_t*)':
/home/jenkins/workspace/Plasma kwin kf5-qt5 SUSEQt5.9/plugins/platforms/x11/standalone/screens_xrandr.cpp:210:
undefined reference to `KWin::Options::currentRefreshRate()'
...
Summary:
The code in events.cpp was problematic as it was called in a Wayland
session. So KWin changed outputs, this gets mirrored to XWayland and
then KWin reacted on the XRandR event and might have even changed the
refresh rate due to that - bad idea.
This change moves the code into the already existing X11EventFilter for
XRandR events in XRandRScreens.
Test Plan: Run kwin_x11 in gdb on Xephyr, breakpoint in new code and triggered XRandR event
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7654
Summary:
By moving the functionality into the Platform API we can also implement
support on other platforms which support this in general (e.g. DRM once
Roman's color adjustment patches landed).
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7447
Summary:
Not needed except for X11/non-composited usage, so should be in the
plugin instead of core.
Platform API is extended to create a decoration renderer.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7444
This change is similar to D7232 and moves the scene_qpainter into a
dedicated plugin. Compared to the XRender case it's more complicated as
the platform plugins need to implement a platform specific backend.
The base implementation for this part used to be in scene_qpainter. As
the idea is to completly move it away from KWin core it would be point
less to still have the backend definition in KWin core, but it cannot
be in the scene plugin as otherwise all platforms need to link the
plugin.
To solve this a new platformsupport subdirectory is added which contains
the scene platform backend as a static library. For the OpenGL scene such
a static library will also be required.
Test Plan: SceneQPainter test still passes, nested compositor still works
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7259
Summary:
KWin::displayWidth and KWin::displayHeight are bound to X11 which
doesn't make much sense on X11. In addition KWin internally knows
the overall display dimensions through the Screens singleton class.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D1798
Summary:
Creating the OutlineVisual is moved into the Platform API. The default
implementation creates the composited OutlineVisual. The X11 standalone
platform overrides it and creates the non composited outline in case no
compositing is used.
Test Plan:
Run kwin_x11 with KWIN_COMPOSE=N and KWIN_COMPOSE=X,
non composited outline and composited outline loaded
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7450
Summary:
This change splits out the X11 specific event filtering into a dedicated
X11EventFilter. It is created in the x11 standalone platform plugin when
the first Edge is being created.
Some of the X11 specific code is removed from ScreenEdges, though more
refactoring is possible in ScreenEdges to share more code between X11
specific and generic implementation.
Test Plan: Run KWin on Xephyr, screen edge approach effect still shows
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7406
Summary:
KWin::updateXTime only delegates into the platform API where the method
is a no-op. The actual implementation is moved into the X11 standalone
platform as it uses QX11Info which is non functional except on the X11
standalone platform.
This change exposes a problem with timestamp handling: on Wayland the
X11 timestamp does not get updated at all, causing e.g. window sync not
work correctly (c.f. bug 374881). We cannot implement the updating in the
same way as QX11Info/Qt xcb platform does it as that would introduce a
blocking roundtrip to XWayland which is dangerous.
As a side-effect this change removes linking to Qt5::X11Extras in kwin
core as it's no longer needed.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7515
