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.
