Like in the drm backend we use an InputEventFilter to turn the backlight
on and off. In this case the filter needs to be always installed as key
event should also turn the screen off. We cannot use a global shortcut
as it would not trigger while the screen is locked.
Unlike the filter in DRM backend only the power key can toggle the
backlight, other key events are ignored. For pointer we are optimistic
and already support enabling the backlight. Double tap to wake is also
implemented, but at least on reference hardware (Nexus 5) doesn't work
as disabling the backlight also disables touch input.
Reviewed-By: Bhushan Shah
All backends already have an init method so far called from the ctor.
This change moves the call to init out of the OpenGL backends and makes
it the responsibility of the creating code to also call init on the
backend.
This change makes it easier to have virtual methods being called during
the initialization.
We use the hw module's backlight and set the color to either 0
or FF depending on whetehr we want to have the screen on or off.
This turns the backlight off properly. It is bound to the toggleBlank
functionality so that we always turn on/off the backlight depending
on whether our compositor is on or off.
In addition we listen to key release events on the power button to
toggle the state.
REVIEW: 126083
This gives a better tear down experience as it goes to black instead
of showing outdated screen and also it disables vsync which fixes a
crash on teardown.
Heavily inspired by how the glxbackend works: present happens on
rendering start and not on end frame. In addition present needs to
check whether there is something to show to not block incorrectly.
This is needed as present might also be called from going to idle.
With this change the Nexus5 has a decend refresh rate shown in the
totally accurate fps effect. Before it was capped at around 30 fps
which indicates that the refresh rate was halfed.
On the tearfing front the change seems to not have any negative
impact.
This changes how we synchronize through vsync. We use a mutex and a
wait condition to synchronize the threads. When presenting the frame
our main gui thread blocks and will be woken up by the vsync event
(or a timeout of max 1 frame time slot). In order to minimize the
blocked time we use the blocksForRetrace functionality from the GLX
compositor.
Given this change we no longer need to tell the compositor that we
are swapping the frame, it's blocked anyway. Also we don't need the
failsafe QTimer anymore.
With this change applied on a Nexus 5 it's succeeding the "Martin
tortures phone test". It doesn't tear anymore and has a smooth
experience.
I'm rather disappointed by the fact that we need to block in order
to get vsync. This means Android/hwcomposer is as bad as GLX. So
much for the "Android stack is so awesome", in fact it's not. Anybody
thinking it's awesome should compare to DRM/KMS and especially atomic
modesetting. Yes it's possible to present frames without tearing and
without having to block the rendering thread.
Reviewed-By: Marco Martin and Bhushan Shah
The newer API is designed for the case that outputs are disabled and
makes sure that we don't have to abuse the aboutToSwapBuffers. This
also prevents possible conflicts between blocking during rendering and
screens being off.
Reviewed-By: Bhushan Shah
According to the hwcomposer documentation:
"It is a (silent) error to have HWC_EVENT_VSYNC enabled when calling
hwc_composer_device.set(..., 0, 0, 0) (screen off)".
Because of that we may not enable vsync directly after toggling the
output, but need to wait till after calling the set call.
Reviewed-by: Bhushan Shah
Apparently we don't get a vsync event for the first frame during startup
which blocks the compositor till the end of days. Thus a timer is added
which calls vsync after 1 sec if we didn't get an event.
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.
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
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.
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.
