This reorders the startup sequence quite a bit:
1. Create QAbstractEventDispatcher and install it on QCoreApplication
2. Create Application
3. Start Xwayland, use thread to get when its ready
4. Create xcb connection
5. perform startup
For using the wayland QPA it needs a patch in QtWayland which will be
part of Qt 5.4.2, otherwise it blocks.
The --xwayland option starts a rootles Xwayland server. If a
rootless Xwayland server is used OperationModeXwayland is used
which is introduced with this change as well.
KWin::connection() uses the property to resolve the value instead of
using QX11Info. In practice this doesn't change anything at the moment,
but allows kwin_wayland to provide an xcb connection without depending
on QX11Info.
As we cannot make xcb_connection_t* available as a metatype, the
property's type is set to void*.
KWin::rootWindow() uses the property to resolve the value instead of
using QX11Info. In practice this doesn't change anything at the moment,
but allows kwin_wayland to provide a root window without depending on
QX11Info.
The porting to Qt5 broke the timestamp handling in many areas. A deeper
look into Qt's xcb plugin shows that the appTime handling is not
sufficient for KWin's need. E.g. the time is only updated in response to
a property notify event if it's for a Qt created window, which is hardly
ever the case in KWin. Another example is that key press/release events
never updated the appTime.
As the functionality in Qt is rather trivial we can do the timestamp
handling ourselves. We filter all events anyway and it is slightly faster
as we don't have to go through the QPA interface any more.
REVIEW: 122636
Adjust the KWIN_DBUS_SERVICE_SUFFIX env variable in a multi-head
scenario instead of adjusting the "org.kde.kwin" DBus service which
we actually don't use in 5.x any more.
REVIEW: 122217
kwin_wayland gains a new command line option to enable libinput support.
This is needed as logind blanks the VT when the session controller
releases the control. So a nested compositor can seriously affect the
primary session. Thus it needs a dedicated command line switch to
enable it.
By default libinput support is disabled for kwin_x11 and can be enabled
for kwin_wayland in case KWin is compiled with libinput support.
All of kwin except the main function goes into a new (private) library
called kwin. Two new kdeinit_executables are created:
* kwin_x11
* kwin_wayland
Both only use a dedicated main_x11.cpp and main_wayland.cpp with the
main function and a KWin::Application subclass and linking the new
kwin library.
The main idea behind this is to be able to perform more sane sanity
checks. E.g. on Wayland we don't need to first test whether we can
create an X11 connection. Instead we should abort if we cannot connect
to the Wayland display. Also the multi-head checks are not needed on
Wayland, etc. etc. As most of that code is in the main function to
simplify it's better to split.
This will also make it easier to diverge more easily in future. The
Wayland variant can introduce more suited command line arguments for
example. This already started by having the --replace option only
available in X11 variant. The Wayland backend is still a window manager,
but doesn't claim the manager selection.
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.
Forwards all xcb events to Workspace::workspaceEvent() which got changed
to process xcb events instead of XEvents. So far all handling is
disabled. Will be re-enabled step by step in the following patches.
We need to connect to this signal instead of waiting for it to time out.
This means we are already starting the window manager while it might be
that we fail.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
Qt 5 only supports raster which means our pixmaps are always non native,
so we don't need the Extension information any more and can drop all
special code handling for mapping a native QPixmap to an X11 pixmap.
Messages in scripts are written to kwin_scripts.pot, messages in
scripting are written to kwin_scripting.pot. The cataloges are loaded in
the configuration interfaces and in main kwin.
REVIEW: 108975
Code section had been in an #ifndef NDEBUG which is the reason why I did
not find the usage of Extensions there and why it always compiled
successfully.
Some data elements which got dropped needed to be added again like a name
for the extension and errorBase, etc.
Sorry for the inconvenience of a semi-broken master.
This got used to check whether the session is being restored and only if
the session was not being restored the multi-head checks used to be
performed. Since 299a78772b823d28cf3c48aff696cfb978d0ae7e the multi-head
checks are no longer bound to not restoring the session which obsoletes
the remaining checks.
REVIEW: 107468
A CMake variable is used to specify the name of the binary.
By default this is "kwin" but building for PA changes the
name to "kwinactive". The variable adjusts all names, e.g.
kwinnvidiahack becomes kwinactivenvidiahack.
The remaining usage of kwinrc in core and libs is replaced
by a cmakedefine for the configuration name and all data
installations are moved to the defined name. Dynamic loading
for scripts & co is adjusted for loading based on defined name.
This change allows the side-by-side installation of both kwin
for desktop and kwin for Plasma Desktop without the known
issues like conflicts in config files or missing build options
if kwin desktop is used for Plasma Active.
Likewise the KCMs are not adjusted as they are not intended to
be used for kwinactive.
REVIEW: 104299
BUG: 296084
FIXED-IN: 4.9.0
CCMAIL: active@kde.org
Options loading is split into three parts:
* reparse configuration
* loading of non-compositing related options
* loading of composited related options not needing CompositingPrefs
At startup the reparsing of configuration is done through a Thread
to gain a little bit of less waiting.
Before something else accesses the KConfig for the first time we
wait for the thread to finish and perform the other two loading
operations of Options.
The settings depending on CompositingPrefs will only be invoked
if a compositor is going to be needed.
REVIEW: 104562
