As a Wayland server KWin does not have to emit additional key repeat
events (unlike X11). The clients are responsible for handling this based
on the provided key repeat information.
Internally KWin needs key repeat, though. E.g. the effects need key
repeat (filtering in Present Windows), window moving by keyboard needs
repeat, etc. etc.
This change introduces the internal key repeat. For each key press a
QTimer is started which gets canceled again on the key release. If the
timer fires it invoked processKey with a new KeyboardKeyAutoRepeat state.
This is handled just like a KeyPress, but states are not updated and
the QKeyEvent has autorepeat set to true.
The event filters check for the autorepeat state and filter the event
out if they are not interested in it. E.g. the filters passing the event
to the Wayland client need to filter it out.
Currently auto-repeat is bound to using libinput. This needs to be
modified. The only backend sending repeated events is X11, thus for
other backends it should be enabled.
Whether creating a timer on each key event is a good idea is something to
evaluate in future.
Reviewed-By: Bhushan Shah
General handling for mouse driven focus and auto raise should and can
be shared between Client and ShellClient. Thus the code is moved to
AbstractClient and invoked from Client::enterNotifyEvent.
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.
