Experimental testing in real world showed it's just a signing issue
in this specific case. The events passed to wayland clients scroll
in correct direction.
With that all the actions are implemented just like on X11.
There are two not yet implemented differences:
* hide splash window when clicking it
* replay event on special window
Implemented in the ForwardEventFilter: before forwarding the event
to the window we check whether a modifier is pressed and perform the
wheel command.
Possible improvements: each axis event triggers the same change, there
is no adjusted scaling.
This change implements the mouse command for modifier (alt/meta) plus
click in InputRedirection so that it also works on Wayland.
Modifier plus mouse wheel is not implemented yet.
For easier code in Options a new method is added which provides the
configured modifier as a Qt::KeyboardModifier instead of a Qt::Key code.
Test case is added which simulates all variants of modifiers plus
supported mouse buttons to trigger move.
this effect, derived from the Maximize one, will
take the place of the manual window position
animation that Plasma tooltip are using.
this should cause less problems as animationg
positions on X is very error prone, plus it's
less jarring when the tooltip sizes changes too,
since that gets animated as well (behavior similar
to Windows7 taskbar tooltips)
REVIEW:126968
Canceling the animation in the animationEnded handler triggers a crash.
This is due to multiple lists being iterated and manipulated at the same
time.
This adds a test case which simulates the crashy situation.
REVIEW: 126975
So far the key handler in the InternalWindowEventFilter used the
PointerInputRedirection's internal window. This had the result that
key events were only delivered to an internal window if the window
was under the cursor.
This change tries sending the event to the latest created and visible
window. Thus e.g. with nested context menus it goes to the current
sub menu as expected. The return value of sendEvent is used to filter
out the event.
The hash was completely useless as we never inserted created
FBConfigInfo* into the hash. This change fixes the usage of the
hash and also ensures that it doesn't leak by deleting all hash
elements on tear down.
Current memleak backtrace from ASAN:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4dc932 in operator new(unsigned long) (/home/kfunk/devel/install/kf5/bin/kwin_x11+0x4dc932)
#1 0x7f3c596de0f3 in KWin::GlxBackend::infoForVisual(unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:454:12
#2 0x7f3c596e7ef4 in KWin::GlxTexture::loadTexture(unsigned int, QSize const&, unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:826:32
#3 0x7f3c596e921e in KWin::GlxTexture::loadTexture(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:869:12
#4 0x7f3c5916e895 in KWin::SceneOpenGL::Texture::load(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1232:12
#5 0x7f3c5917019a in KWin::OpenGLWindowPixmap::bind() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1681:20
#6 0x7f3c5916fce0 in KWin::SceneOpenGL::Window::bindTexture() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1288:12
#7 0x7f3c5917294b in KWin::SceneOpenGL::Window::beginRenderWindow(int, QRegion const&, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1349:10
#8 0x7f3c59176f24 in KWin::SceneOpenGL2Window::performPaint(int, QRegion, KWin::WindowPaintData) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1510:10
#9 0x7f3c5916d410 in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1161:9
#10 0x7f3c5916cbc9 in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1147:9
#11 0x7f3c5922e92f in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:502:9
#12 0x7f3c590d7bc5 in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:606:5
#13 0x7f3c5922c979 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:465:9
#14 0x7f3c590d2b38 in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) /home/kfunk/devel/src/kf5/kwin/scene.cpp:478:5
#15 0x7f3c590ced89 in KWin::Scene::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene.cpp:381:9
#16 0x7f3c5916b2b1 in KWin::SceneOpenGL2::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1098:12
#17 0x7f3c590c8bd3 in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:200:9
#18 0x7f3c5922b062 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:422:9
#19 0x7f3c590c791f in KWin::Scene::paintScreen(int*, QRegion const&, QRegion const&, QRegion*, QRegion*, QMatrix4x4 const&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:150:5
#20 0x7f3c5915e500 in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:751:9
#21 0x7f3c5907ea3c in KWin::Compositor::performCompositing() /home/kfunk/devel/src/kf5/kwin/composite.cpp:726:29
#22 0x7f3c5907c230 in KWin::Compositor::startupWithWorkspace() /home/kfunk/devel/src/kf5/kwin/composite.cpp:347:5
#23 0x7f3c59079bbb in KWin::Compositor::slotCompositingOptionsInitialized() /home/kfunk/devel/src/kf5/kwin/composite.cpp:283:9
#24 0x7f3c59076084 in KWin::Compositor::setup() /home/kfunk/devel/src/kf5/kwin/composite.cpp:184:9
#25 0x7f3c598b165f in KWin::Compositor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) /home/kfunk/devel/build/kf5/kwin/moc_composite.cpp:263:18
#26 0x7f3c52de67b0 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2b67b0)
#27 0x7f3c536ab9db in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15b9db)
REVIEW: 127096
This makes QCursor::pos and QCursor::setPos function correctly. KWin
actually wouldn't need it as KWin has the KWin::Cursor replacement, but
it allows Qt internal API to have it function correctly and also the
zoom effect does use QCursor::setPos.
The mapping is slightly inspired by the mapping in QtWayland.
But the mapping in QtWayland seems wrong. E.g. there is a linux kernel
button called BTN_BACK which is not mapped to Qt::BackButton.
Anyway we are not really interested in the mapping being 100 % correct
for the case in KWin. KWin internally uses only very few mouse buttons
and all others are only relevant to figure out whether buttons are
pressed. The button code itself is passed to the seat with the native
code.
The MoveResizeWindowTest is extended by a test case to verify that
the move only ends once all mouse buttons are released. So far this
is not yet the case as KWin has an incorrect mapping of buttons to
Qt::MouseButtons.
So far KSldApp was always either in state AcquiringLock or Unlocked
during the tests. Due to a fix in WaylandServer it now can also enter
the Locked state. But this is timing related and also depends on whether
the greeter works at all. E.g. on build.kde.org the greeter fails to
start, so it never enters the Locked state.
The adjusted test now considers that the state might have changed to
Locked and expects one additional signal to be emitted.
The event filter is only used to let Qt compose a QKeyEvent from an
x11 event for grabbed key events. On Wayland we don't need it as we
can generate good QKeyEvents ourself. This means less event processing
as the events no longer need to pass through the
Workspace::workspaceEvent.
In addition it fixes a regression in LockScreenTest::testEffectsKeyboard
caused by the LockScreenEventFilter sending a QKeyEvent to KSldApp.
This event got intercepted by the global event filter making the test
rightfully fail.
the shadow can be deleted deferred from an update
there's a slight chance, to be eg. triggered by clients
blocking compositing, that the compositor is suspended in the same
cycle and the effects pointer (and scene and context) thus gone
CCBUG: 356938
FIXED-IN: 5.6
REVIEW: 126441
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
If the output is off a double tap (touch) can re-enable it. The two
taps have to happen in the double click interval (we don't have
something better and it kind of matches) and have to be by only one
touch point. If there are multiple touch points it's not considered
as a double tap. A todo is to restrict the possible distance of the
two taps to one thumb.
Tested-By: Marco Martin
So far the DrmOutput connected to all input events when going into
power saving. As we now have the input filters it's better to just
install a filter when an output goes into powersave and remove the
input filter again when all outputs are enabled again.
To make this work InputRedirection gains a new method to add a new
filter as the first filter. This is a potentially dangerous method
as it allows to have a filter before LockScreenFilter gets the
events. But in case of DPMS it's something we actually want.
A nice new feature possible with the input filter is that we can
filter out the event which re-enables the outputs. Thus when getting
on a system with output off and screen locked, the first key hit
doesn't go to the lock screen.
Reviewed-By: Bhushan Shah
BUG: 341201
Fixed-in: 5.6.0 (Wayland-only)
Similar to the change regarding pointer and touch a
KeyboardInputRedirection is created. The Xkb class is also moved to
the new files keyboard_input.h and keyboard_input.cpp.
Just like in the case of PointerInputRedirection no signals are added,
but the existing signals in InputRedirection are directly invoked.
CI system is adjusted, so that OpenGL should work. At least latest
run didn't show the EGL warnings in the lock screen test. So let's
try to enable again. It's possible that this fails horribly. If that's
the case I'll revert again.
The dontCrashGlxgearsTest is kept on QPainter as locally it crashes
on teardown (needs fixing).
This is a complementary commit to 4c7450a1f6:
After Workspace gets destroyed it's possible that ShellClient's are still
around. Their tear down should not crash due to calling into Workspace.
All pointer related code is moved into a new class called
PointerInputRedirection.
The main idea is to simplify the code and make it easier to maintain.
Therefore also a few changes in the setup were performed:
* before init() is called, no processing is performed
* init() is only called on Wayland and after Workspace is created
* init property is set to false once Workspace or WaylandServer is
destroyed
Thus code can operate on the following assumptions:
* Workspace is valid
* WaylandServer is valid
* ScreenLocker integration is used
The various checks whether there is a waylandServer() and whether
there is a seat are no longer needed.
Some of the checks have been reordered to be faster in the most common
use case of using libinput. E.g. whether warping is supported is first
evaluated by the variable bound to whether we have libinput and only if
that is false the backend is checked.
The new class doesn't have signals but invokes the signals provided
by InputRedirection. I didn't want to add new signals as I consider
them as not needed. The areas in KWin needing those signals should
be ported to InputEventFilters.
So far the area based edges connected directly to global pointer pos
changed in InputRedirection. This didn't allow proper checking whether
the edge was triggered (e.g. missing timestamp).
This change merges the functionality into the new input filter mechanism.
There is now a dedicated input filter for screen edges, installed after
lock screen and before effects. It always passes events on, but also passes
all events through ScreenEdges to handle the activation. As it's installed
after the lock screen filter we don't need to check for screen locked any
more.
The code is now similar strucutured to the existing X11 based variants
and maybe will allow to also merge the X11 variant with the new one.
The logic should not be tied to whether libinput is used. It's relevant
for all Wayland backends whether they use libinput or not.
In addition this should generate a pointer motion event, so that proper
processing can take place and we get proper pointer enter events.
The test removes the second screen while the cursor is on it. This
should warp the pointer to the center of first screen and trigger
a focus enter event.
As can be seen by the expect failures currently it's bound to libinput
and also doesn't process the event as if it were a pointer event.
