This reverts commit c09d63d192.
The test results we got indicate that on NVIDIA the problems with the
threaded rendering loop do not exist and at the same time the rendering
result improves a lot. As Qt still disables the threaded rendering loop
for the problematic drivers, it's better to not force the basic rendering
loop.
This servers two purposes.
1. it makes KWin/5 co-installable with KWin/4 as now binary and
all libraries etc. are renamed or installed to a different
location.
2. In future we need a dedicated X11 and Wayland main function
anyway. Thus it makes most sense to rename to kwin_x11 directly
instead of first renaming to kwin5. The reason why we need to
have dedicated main functions is that kwin needs to check early
whether X11 is working or Wayland is working. Right now the first
thing kwin does is trying to connect to the XServer. This happens
before the QApplication is constructed and before command line
args are processed. On Wayland we won't want to test whether we
can connect to the XServer. As it's too early to check whether we
are starting kwin for X11 or Wayland the most convenient way is to
have dedicated binaries - thus a rename is needed. Just renaming
kwin for wayland is also not a good idea as in future the "main"
kwin will be for wayland not for X11. Another case for the dedicated
binaries is the Application class, which right now first tries to
claim the X11 Window Manager Selection. Again on Wayland even with
XWayland we won't need that. KWin will be the window manager for
XWayland if KWin is the Wayland compositor. There is no need to even
try to support anything else. Most likely it will even be KWin to
start the XWayland server, so we can be sure that there is no other
WM running and thus no need to claim the selection and abort if it
fails.
REVIEW: 118266
Setting the ApplicationDomain to kwin, both use the kwin catalog.
The left-over code for catalogs is removed. Note for adjustments:
* scripting doesn't provide an own catalog
* scripts are extracted but there are no scripts with i18n
This commit basically makes KWin stop using suspend-resumeStartup
methods from KSMServer. The idea is to launch things on parallel and
this is doing exactly the contrary.
Reviewed-by: Martin Gräßlin <mgraesslin@kde.org>
KWin requires the xcb plugin otherwise KWin crashes when the first
xcb/xlib code is called. First KWin tries to set the QT_QPA_PLATFORM
to "xcb", but that doesn't protect against the command line switch.
Thus KWin also verifies that after constructing the QGuiApplication
the platform name is set to xcb, if not it exits gracefully with a
useful error message instead a crash.
To make that work the KWinSelectionOwner has to be changed to a
pointer and be delayed constructed, otherwise the crash already happens
in the KSelectionOwner.
Furthermore a small sanity check on the plugin is performed by checking
whether KWin can get the XDisplay from the QPA. If not it means that the
QPA plugin was compiled with -no-xcb-xlib which KWin doesn't support, it
still uses XLib at various places. If KWin doesn't get the Display, it
exits gracefully with a clear error message.
CCBUG: 331880
REVIEW: 116669
Picked Wayland by default instead of X11 causing KWin to abort
startup if there is no Wayland backend.
Important lesson: test your changes also on X11 and not just on
Wayland!
In the Wayland world we need to have a compositor. This means we have to
enforce that the compositor is running. If the setup fails we have to
quit, because it doesn't make any sense any more to be running.
A new method requiresCompositing() is added to the Application. If it
returns true the useCompositing option will always return true and the
unredirect fullscreen option will always return false. That way
compositing is enforced at startup and cannot end by unredirecting.
In addition this method is checked if actions are performed which would
suspend compositing. E.g. the shortcut to toggle compositing. Restarting
the compositor is still possible in order to change the selected
compositing backend without a restart. But if it fails KWin will quit.
Returns true if the OperationMode requires KWin to composite to a
Wayland surface. This replaces the checks for the WaylandBackend or env
variable used so far in the construction of the Scene.
This enum describes how KWin is operating with the available windowing
systems. By default KWin is using the OperationModeX11, but if the
Wayland backend gets started KWin is using the OperationModeWaylandAndX11
This will be extended in future when XWayland and Wayland only become
viable options.
Instead we generate an export header for kdeinit_kwin and use it
to declare the KWIN_EXPORT. With this change our libs don't include
any KDE4Support headers any more. One step closer to no KDE4Support.
Replaced by KWIN_VERSION_STRING where useful. Support information
no longer contains the SC version number. We have to see whether
there will be a useful framework based platform information.
The main purpose of the opengl testapp was to set the environment
variable LIBGL_ALWAYS_INDIRECT if direct rendering is not supported
before glx gets initialized.
With Qt5 we may no longer set this environment variable. QtQuick
requires direct rendering. On IvyBridge QtQuick is crashing if the
variable is set. Thus we are no longer allowed to set it and thus the
complete test becomes pointless.
The test app basically whitelisted most drivers anyway, the only
drivers which were problematic are the proprietary Catalyst drivers.
It that's still a problem we can also disable OpenGL compositing on
those drivers through the recommendation in the GLPlatform.
This also means that the KWIN_DIRECT_GL variable is no longer useful.
The variable is set not from config nor anywhere else when kwin is
started through ksmserver by startkde.
In addition the KGlobal implementation is twisted compared to the kcminit
config behavior (the config value defaults to true, not false - ie. if the
variable isn't set (by kcm init) it's reasonable to assume true either.
Therefore and in alignment with PW/2, the environment is read directly and
on absence resolved to "true".
To control the behavior, please export KDE_MULTIHEAD=true/false before starting KWin
(eg. in /usr/bin/startkde)
This reverts commit ab6d5c048a25bcb2f5bdb822ba3eda64019c61bc.
REVIEW: 112579
CCBUG: 256242
During startup we only create the request, the reply will be fetched
once the atom is needed.
To make proper use of this async behavior the creation of Atoms is
moved directly to the claim of the manager selection, so they can be
fetched while we wait for the previous manager selection to give up
on it.
The crash count checking does not depend on whether or not we will
be able to claim the window manager selection. As claiming the selection
can take up to one second we should try to get as many checks which do
not depend on it out.
KSessionManager is deprecated and there is no replacement yet. So
let's get rid of the warnings for now. Needs to be re-added once
there is a working QSessionManager again.
Done in one step as it requires changes which are better suited with a
QApplication.
To not need to parte the QCommandLineParser around the needed arguments
are added to the KWin::Application through setters and the crash count
is available through a static getter/setter pair.
Wrapped in xcbutils.
In addition the check whether another WM is running in main.cpp is
improved by doing a checked request and directly checking for the
error. If there is an error, KWin puts out an error message and
quits.
