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 4c7450a1f6c314fe71768b95067ae5d48cc73811:
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.
If the pointer is warped the position change should be treated like
a change coming from the input device. Our normal processing should
take place.
A problem in this case is the timestamp to pass to the wayland server.
Normally our timestamps come from the backend/libinput and we don't
know the next one. As an intermediate solution we just use the last
timestamp on the seat. In future a solution could be to not use the
backend's timestamp at all, but have our own timestamp handling.
When warping a pointer through Cursor::setPos it should be processed
just like any other pointer event. It should generate enter/leave event,
create motion events, etc. This is currently not the case as the test
shows.
A new test case which ensures that when stacking order changes the
pointer focus gets re-evaluated and updated. I was positively surprised
to notice that this already works.
Noticed two other problems while writing the test case:
* warping pointer does not re-evaluate the pointer pos
* deleting a ShellSurface (client) does not destroy the ShellClient (server)
When the screen gets locked any existing sequence gets cancelled
and the focused touch surface gets reset. While screen is locked
touch events are filtered to only go to lock screen or input methods.
Test case is added for touch event during lock screen.
Reviewed-By: Bhushan Shah
Instead of only making the active client the focused keyboard surface,
the method now also performs the lock screen security restriction.
Also just like udatePointerWindow the method becomes public, so that
it can be used from the LockScreenEventFilter and is connected for
lock state changes. This means as soon as the screen locks the current
focused keyboard surface will get a leave event and get an enter event
once the screen unlocks.
The auto test is adjusted to verify these new conditions.
Reviewed-By: Bhushan Shah
InputRedirection connects to lockStateChanged to udate the current
pointer window. This way we can ensure that the current pointer
surface gets reset as soon as the screen locks (c.f. the expect
fail in the autotest) and also that it restores to the surface under
the mouse once the screen is unlocked.
The relevant code was not yet lock screen aware and performed an
early exit. Part of the code was fine, e.g. findToplevel is lock
screen aware. So this change adjusts the methods for updating the
internal window and decoration to be lock screen aware, that is they
get reset. With that updatePointerWindow is also lock screen aware.
Thus the LockScreenFilter can also use updatePointerWindow just like
the normal handling and does not need to reimplement parts of it. As
it now relies on other code being correct it has an additional check
to verify that the current pointer surface is a surface which is allowed
to get events. If it isn't the events are not forwarded.
Reviewed-By: Bhushan Shah
The main motivation of this change is to remove the spaghetti code
in the input event handling. Each area of processing (e.g. lock screen)
is moved into a dedicated event filter. Processing the events now just
means calling a virtual method on each of the filters. As soon as the
method returns true, the processing is stopped.
This allows to have the security for the lock screen just in one place:
whenever the screen is locked the event filter can ensure that the events
are not further processed.
Currently all event filters are implemented directly in input.cpp and
are registered by InputRedirection itself. In future it would be better
to have those moved to the area they belong to and get registered from
there. E.g. the input filter for EffectsHandlerImpl should be created
by EffectsHandlerImpl. This requires an improved API to ensure that the
filters are installed in the correct sequence.
Martin Gräßlin
Marco Martin
Thomas Lübking
Kevin Funk
Vladimir Panteleev