Note: qt5-qpa-hwcomposer-plugin does the vsync in a different way:
it uses a wait condition to truly block in present till the vsync.
Maybe we need to do that as well.
Very basic: all screens have same size and are ordered from left to
right. It's mostly meant to allow easy test cases with multi-screen.
The quick tiling test demonstrates how it's used.
Based on a previous patch done by David Edmundson and heavily
inspired by qt5-qpa-hwcomposer-plugin [1].
The change requires a newer libhybris than the one used by Ubuntu. In
fact it allows to build against current master (at the day of writing [2]).
REVIEW: 125606
[1] https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin
[2] bd6df6a306
Libinput does work on libhybris enabled devices. There is no need to
use Android's input stack. This simplifies our code a lot and increases
sharing with normal Linux systems.
What's tricky is to convince the system to use libinput through with our
logind helper. Logind fails to open the files for us if we start KWin
over either ssh or adb shell. We need to get it into a proper session, so
only a kwin started through a helper like simplelogin will be able to use
libinput.
REVIEW: 125608
The backend is based on drm's gbm backend and also uses the GBM
platform, but with the default display allowing the driver to pick
a device. In addition it doesn't use a surface, but a surfaceless
context with a framebuffer object to render to. Given that it diverged
too much from drm's backend to allow more code sharing.
If KWin is started from a tty it gets a proper driver, if KWin is started
in a X11 session it only gets llvmpipe. Given that there is a chance that
the autotests using the virtual backend will fail. In that case a follow
up patch will enforce either O2 or Q.
A new backend which doesn't present the rendered output. It uses a
QPainter scene, renders to a QImage but doesn't present it anywhere.
Thus a real virtual backend.
By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS
the backend creates a temporary dir, prints the path to std-out and
saves each rendered frame into that directory. Of course with exit it
will be deleted again.
Distributions do package each backend plugin in a dedicated package,
which means just because KWin got compiled with a specific backend,
doesn't mean it is also available at runtime.
In order to better support this reality this change introduces a
list-backends command line option. Each of the plugins got the json
metadata extended by the KPlugin syntax, so that we have a name and
description to print.
As we already locate all plugins anyway, the additional findPlugins for
the selected backend is changed to search the list of all plugin meta
data.
When pressing right control key the input gets grabbed/released.
The grab is for both keyboard and pointer and pointer is also confined
to the window.
How to grab/ungrab is added to the window title.
Our server announces the DpmsManagerInterface and in the DRM backend
we announce support for Dpms on the OutputInterface (if the Output
supports it) and we connect to changing Dpms requests.
If an Output went into DPMS standby we need to re-enable the Output
once we get any input event.
For this we connect to the signals of InputRedirection once we go
to standby. Once we enable again, we disconnect (to not handle the
events all the time), blank the screen (initial modesetting) and
trigger a complete repaint.
Let's rather not build the plugin if we don't have the dependency
then building it without OpenGL support. Simplifies the code a bit
and makes the backend overall more useful and goes along with e.g.
the Wayland one which has EGL also as a hard dependency for the
plugin.
REVIEW: 124697
It doesn't make much sense any more as we do no longer link EGL since the
switch to epoxy. And epoxy pulls it in at runtime if needed.
Even more on Wayland it's just plain stupid to have EGL disabled. So
removing the option just simplifies our code base without any
disadvantages.
REVIEW: 124695
During cleanup the KWayland::OutputInterface is already destroyed before
we hit the cleanup code of DrmOutput. Thus guard with a QPointer to not
delete twice.
We don't need to queue the method invokation any more to ensure the
Wayland server connection is flushed since we have the dispatch method
in waylandServer().
Libhybris input events are generated in a different thread, but we want
them in the main thread (InputRedirection and KWayland are not (yet)
thread safe). Thus all events need to be send to the main thread using
QMetaObject::invokeMethod.
Unfortunately on libhybris enabled systems libinput doesn't work, thus
the backend needs to handle input events which can be read from hybris.
So far the backend only handles touch events properly, though some
aspects look wrong. E.g. motion gives only for one touch contact point.
Unfortunately the documentation is quite weak, so there might be
something important missing.
