yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/input.h

393 lines
13 KiB
C
Raw Normal View History

Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2013 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#ifndef KWIN_INPUT_H
#define KWIN_INPUT_H
#include <kwinglobals.h>
Update x11Time when a global shortcut is pressed KGlobalAccel sets the timestamp as a property and we need to set our x11Time to it otherwise following keyboard grabs might fail. Requires 61e2a156678eef033b2629f7c72530dc78d7c3ac in kglobalaccel.
2015-02-19 09:38:49 +00:00
#include <QAction>
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
#include <QHash>
#include <QObject>
#include <QPoint>
Handle interaction with window decoration directly in InputRedirection So far input events were sent through Xwayland which is not needed as we have all information available. Even more it had the pointer surface on the wrong window when interacting with decorations as it was on the window and not on the decoration.
2015-06-03 16:09:54 +00:00
#include <QPointer>
Pass pointer events through the effect system InputRedirection forwards pointer events (currently motion, press and release) through the EffectsHandlerImpl for the case that an effect has intercepted pointer events. If the KWin operation mode is not X11 only, the window for intercepting the mouse events is no longer created.
2013-06-26 09:40:30 +00:00
#include <QEvent>
Redirect pointer events to the Toplevel InputRedirection keeps track of the Toplevel which is currently the one which should get pointer events. This is determined by checking whether there is an Unmanaged or a Client at the pointer position. At the moment this is still slightly incorrect, e.g. pointer grabs are ignored, unmanaged are not checked whether they are output only and input shapes are not yet tracked. The pointer events are delivered to the Toplevel as: * enter * leave * move * button press * axis event Nevertheless move events are still generated in InputRedirection through xcb test for simplicity. They are still send to the root window, so all windows get mouse move. Button press and axis are generated only in the implementations of the event handlers and delivered directly to the window, so other windows won't see it.
2013-07-01 06:37:59 +00:00
#include <QWeakPointer>
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
#include <config-kwin.h>
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
[wayland] Add a plugin for kglobalaccel The KGlobalAccelD which gets created by KWin needs a plugin for the platform specific parts. This change introduces such a plugin. It's linked against kwin so that it can integrate with the core. On enable the plugin registers itself in the InputRedirection and GlobalShortcutsManager checks the plugin whether a shortcut got triggered. As the loading of the plugin must happen after InputRedirection is fully created a dedicated init method is added to InputRedirection. REVIEW: 124187
2015-06-26 11:47:08 +00:00
class KGlobalAccelInterface;
Beginning of global shortcut handling inside KWin A new GlobalShortcutsManager is introduced which is responsible for holding the registered shortcuts and triggering the matching action. The InputRedirection checks with the GlobalShortcutManager whether a key press event triggers a global shortcut and stops processing the event in that case. At the moment the GlobalShortcutsManager only supports the very basics for KWin internal usage. External applications can not yet make usage of the global shortcut system inside KWin.
2013-07-10 09:41:16 +00:00
class QKeySequence;
Don't include xkbcommon/xkbcommon.h in input.h, forward-declare instead Some systems (e.g. openSuSE) don't install the xkbcommon header into /usr/include/xkbcommon/xkbcommon.h (which is always in the include path), but instead into a subdirectory, which is in the openSuSE case /usr/include/pkg/libxkbcommon/xkbcommon/xkbcommon.h. This means that e.g. kcm_kwinrules will not compile there since it includes input.h REVIEW: 117069
2014-03-28 08:41:48 +00:00
struct xkb_context;
struct xkb_keymap;
struct xkb_state;
typedef uint32_t xkb_mod_index_t;
typedef uint32_t xkb_keysym_t;
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
namespace KWin
{
Beginning of global shortcut handling inside KWin A new GlobalShortcutsManager is introduced which is responsible for holding the registered shortcuts and triggering the matching action. The InputRedirection checks with the GlobalShortcutManager whether a key press event triggers a global shortcut and stops processing the event in that case. At the moment the GlobalShortcutsManager only supports the very basics for KWin internal usage. External applications can not yet make usage of the global shortcut system inside KWin.
2013-07-10 09:41:16 +00:00
class GlobalShortcutsManager;
Redirect pointer events to the Toplevel InputRedirection keeps track of the Toplevel which is currently the one which should get pointer events. This is determined by checking whether there is an Unmanaged or a Client at the pointer position. At the moment this is still slightly incorrect, e.g. pointer grabs are ignored, unmanaged are not checked whether they are output only and input shapes are not yet tracked. The pointer events are delivered to the Toplevel as: * enter * leave * move * button press * axis event Nevertheless move events are still generated in InputRedirection through xcb test for simplicity. They are still send to the root window, so all windows get mouse move. Button press and axis are generated only in the implementations of the event handlers and delivered directly to the window, so other windows won't see it.
2013-07-01 06:37:59 +00:00
class Toplevel;
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
class Xkb;
Refactor input event handling to be based on filters 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.
2016-02-03 14:17:49 +00:00
class InputEventFilter;
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
Handle interaction with window decoration directly in InputRedirection So far input events were sent through Xwayland which is not needed as we have all information available. Even more it had the pointer surface on the wrong window when interacting with decorations as it was on the window and not on the decoration.
2015-06-03 16:09:54 +00:00
namespace Decoration
{
class DecoratedClientImpl;
}
Ensure screens are created before fully setting up libinput Parts rely on screens being available but input might be created before screens are available. Thus connect to signal and delay.
2015-03-30 06:55:41 +00:00
namespace LibInput
{
class Connection;
}
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
/**
* @brief This class is responsible for redirecting incoming input to the surface which currently
* has input or send enter/leave events.
*
* In addition input is intercepted before passed to the surfaces to have KWin internal areas
* getting input first (e.g. screen edges) and filter the input event out if we currently have
* a full input grab.
*
*/
[wayland] Add a plugin for kglobalaccel The KGlobalAccelD which gets created by KWin needs a plugin for the platform specific parts. This change introduces such a plugin. It's linked against kwin so that it can integrate with the core. On enable the plugin registers itself in the InputRedirection and GlobalShortcutsManager checks the plugin whether a shortcut got triggered. As the loading of the plugin must happen after InputRedirection is fully created a dedicated init method is added to InputRedirection. REVIEW: 124187
2015-06-26 11:47:08 +00:00
class KWIN_EXPORT InputRedirection : public QObject
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
{
Q_OBJECT
public:
enum PointerButtonState {
PointerButtonReleased,
PointerButtonPressed
};
enum PointerAxis {
PointerAxisVertical,
PointerAxisHorizontal
};
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
enum KeyboardKeyState {
KeyboardKeyReleased,
KeyboardKeyPressed
};
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
virtual ~InputRedirection();
[wayland] Add a plugin for kglobalaccel The KGlobalAccelD which gets created by KWin needs a plugin for the platform specific parts. This change introduces such a plugin. It's linked against kwin so that it can integrate with the core. On enable the plugin registers itself in the InputRedirection and GlobalShortcutsManager checks the plugin whether a shortcut got triggered. As the loading of the plugin must happen after InputRedirection is fully created a dedicated init method is added to InputRedirection. REVIEW: 124187
2015-06-26 11:47:08 +00:00
void init();
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
/**
* @return const QPointF& The current global pointer position
*/
const QPointF &globalPointer() const;
/**
* @brief The last known state of the @p button. If @p button is still unknown the state is
* @c PointerButtonReleased.
*
* @param button The button for which the last known state should be queried.
* @return KWin::InputRedirection::PointerButtonState
*/
PointerButtonState pointerButtonState(uint32_t button) const;
Integrate KWin::Cursor with InputRedirection New inheriting class which uses the InputRedirection to track the cursor position. It doesn't support warping of cursor. This introduces a slight dependency loop in the startup. Cursor needs to be created after the WaylandBackend to ensure that the operation mode is set correctly. But the WaylandBackend itself is accessing Cursor. It should be safe as inside the WaylandBackend it's only accessed after callbacks.
2013-06-26 12:32:03 +00:00
Qt::MouseButtons qtButtonStates() const;
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
Qt::KeyboardModifiers keyboardModifiers() const;
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
Beginning of global shortcut handling inside KWin A new GlobalShortcutsManager is introduced which is responsible for holding the registered shortcuts and triggering the matching action. The InputRedirection checks with the GlobalShortcutManager whether a key press event triggers a global shortcut and stops processing the event in that case. At the moment the GlobalShortcutsManager only supports the very basics for KWin internal usage. External applications can not yet make usage of the global shortcut system inside KWin.
2013-07-10 09:41:16 +00:00
void registerShortcut(const QKeySequence &shortcut, QAction *action);
Update x11Time when a global shortcut is pressed KGlobalAccel sets the timestamp as a property and we need to set our x11Time to it otherwise following keyboard grabs might fail. Requires 61e2a156678eef033b2629f7c72530dc78d7c3ac in kglobalaccel.
2015-02-19 09:38:49 +00:00
/**
* @overload
*
* Like registerShortcut, but also connects QAction::triggered to the @p slot on @p receiver.
* It's recommended to use this method as it ensures that the X11 timestamp is updated prior
* to the @p slot being invoked. If not using this overload it's required to ensure that
* registerShortcut is called before connecting to QAction's triggered signal.
**/
template <typename T>
void registerShortcut(const QKeySequence &shortcut, QAction *action, T *receiver, void (T::*slot)());
Support for global pointer shortcut activation Sharing most of the code with keyboard shortcuts allowing to trigger a QAction with holding modifiers and clicking a mouse button.
2013-07-14 20:52:58 +00:00
void registerPointerShortcut(Qt::KeyboardModifiers modifiers, Qt::MouseButton pointerButtons, QAction *action);
Support for global pointer axis activation Just as pointer buttons...
2013-07-15 09:26:56 +00:00
void registerAxisShortcut(Qt::KeyboardModifiers modifiers, PointerAxisDirection axis, QAction *action);
[wayland] Add a plugin for kglobalaccel The KGlobalAccelD which gets created by KWin needs a plugin for the platform specific parts. This change introduces such a plugin. It's linked against kwin so that it can integrate with the core. On enable the plugin registers itself in the InputRedirection and GlobalShortcutsManager checks the plugin whether a shortcut got triggered. As the loading of the plugin must happen after InputRedirection is fully created a dedicated init method is added to InputRedirection. REVIEW: 124187
2015-06-26 11:47:08 +00:00
void registerGlobalAccel(KGlobalAccelInterface *interface);
Beginning of global shortcut handling inside KWin A new GlobalShortcutsManager is introduced which is responsible for holding the registered shortcuts and triggering the matching action. The InputRedirection checks with the GlobalShortcutManager whether a key press event triggers a global shortcut and stops processing the event in that case. At the moment the GlobalShortcutsManager only supports the very basics for KWin internal usage. External applications can not yet make usage of the global shortcut system inside KWin.
2013-07-10 09:41:16 +00:00
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
/**
* @internal
*/
void processPointerMotion(const QPointF &pos, uint32_t time);
/**
* @internal
*/
void processPointerButton(uint32_t button, PointerButtonState state, uint32_t time);
/**
* @internal
*/
void processPointerAxis(PointerAxis axis, qreal delta, uint32_t time);
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
/**
* @internal
*/
void processKeyboardKey(uint32_t key, KeyboardKeyState state, uint32_t time);
/**
* @internal
*/
void processKeyboardModifiers(uint32_t modsDepressed, uint32_t modsLatched, uint32_t modsLocked, uint32_t group);
/**
* @internal
**/
void processKeymapChange(int fd, uint32_t size);
[wayland] Add support for processing touch events InputRedirection gains basic support for processing touch events which are delegated to KWayland::Server. WaylandBackend accepts touch events from KWayland::Client and delegates them to the InputRedirection.
2015-03-25 13:50:14 +00:00
void processTouchDown(qint32 id, const QPointF &pos, quint32 time);
void processTouchUp(qint32 id, quint32 time);
void processTouchMotion(qint32 id, const QPointF &pos, quint32 time);
void cancelTouch();
void touchFrame();
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
[wayland] Add support for pointer warping in InputRedirectionCursor With libinput we do can support warping pointers, let's do it.
2015-06-05 04:43:12 +00:00
bool supportsPointerWarping() const;
void warpPointer(const QPointF &pos);
Refactor input event handling to be based on filters 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.
2016-02-03 14:17:49 +00:00
void uninstallInputEventFilter(InputEventFilter *filter);
Toplevel *findToplevel(const QPoint &pos);
GlobalShortcutsManager *shortcuts() const {
return m_shortcuts;
}
void insertTouchId(quint32 internalId, qint32 kwaylandId);
qint32 touchId(quint32 internalId);
void removeTouchId(quint32 internalId);
Add check for lock screen in InputRedirection::updateKeyboardWindow 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
2016-02-10 13:40:56 +00:00
void updateKeyboardWindow();
Implement lock screen security for touch events 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
2016-02-10 15:43:06 +00:00
void updateTouchWindow(const QPointF &pos);
Add check for lock screen in InputRedirection::updateKeyboardWindow 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
2016-02-10 13:40:56 +00:00
Redirect pointer events to the Toplevel InputRedirection keeps track of the Toplevel which is currently the one which should get pointer events. This is determined by checking whether there is an Unmanaged or a Client at the pointer position. At the moment this is still slightly incorrect, e.g. pointer grabs are ignored, unmanaged are not checked whether they are output only and input shapes are not yet tracked. The pointer events are delivered to the Toplevel as: * enter * leave * move * button press * axis event Nevertheless move events are still generated in InputRedirection through xcb test for simplicity. They are still send to the root window, so all windows get mouse move. Button press and axis are generated only in the implementations of the event handlers and delivered directly to the window, so other windows won't see it.
2013-07-01 06:37:59 +00:00
public Q_SLOTS:
void updatePointerWindow();
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
Q_SIGNALS:
/**
* @brief Emitted when the global pointer position changed
*
* @param pos The new global pointer position.
*/
void globalPointerChanged(const QPointF &pos);
/**
* @brief Emitted when the state of a pointer button changed.
*
* @param button The button which changed
* @param state The new button state
*/
Integrate KWin::Cursor with InputRedirection New inheriting class which uses the InputRedirection to track the cursor position. It doesn't support warping of cursor. This introduces a slight dependency loop in the startup. Cursor needs to be created after the WaylandBackend to ensure that the operation mode is set correctly. But the WaylandBackend itself is accessing Cursor. It should be safe as inside the WaylandBackend it's only accessed after callbacks.
2013-06-26 12:32:03 +00:00
void pointerButtonStateChanged(uint32_t button, InputRedirection::PointerButtonState state);
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
/**
* @brief Emitted when a pointer axis changed
*
* @param axis The axis on which the even occurred
* @param delta The delta of the event.
*/
Integrate KWin::Cursor with InputRedirection New inheriting class which uses the InputRedirection to track the cursor position. It doesn't support warping of cursor. This introduces a slight dependency loop in the startup. Cursor needs to be created after the WaylandBackend to ensure that the operation mode is set correctly. But the WaylandBackend itself is accessing Cursor. It should be safe as inside the WaylandBackend it's only accessed after callbacks.
2013-06-26 12:32:03 +00:00
void pointerAxisChanged(InputRedirection::PointerAxis axis, qreal delta);
InputRedirection emits a signal when the modifiers change Used by Cursor to properly emit the mouseChanged signal which for historic reasons includes the keyboard modifiers. Again some fiddling around with the autotests and kcmrules needed to make it compile. This needs improvement!
2013-07-02 10:16:03 +00:00
/**
* @brief Emitted when the modifiers changes.
*
* Only emitted for the mask which is provided by Qt::KeyboardModifiers, if other modifiers
* change signal is not emitted
*
* @param newMods The new modifiers state
* @param oldMods The previous modifiers state
*/
void keyboardModifiersChanged(Qt::KeyboardModifiers newMods, Qt::KeyboardModifiers oldMods);
Add signal InputRedirection::keyStateChanged Complements all other signals for internal usage that there is an input event. Needed by e.g. DPMS implementation to re-enable the outputs.
2015-08-31 06:55:26 +00:00
/**
* @brief Emitted when the state of a key changed.
*
* @param keyCode The keycode of the key which changed
* @param oldMods The new key state
*/
void keyStateChanged(quint32 keyCode, InputRedirection::KeyboardKeyState state);
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
private:
Pass pointer events through the effect system InputRedirection forwards pointer events (currently motion, press and release) through the EffectsHandlerImpl for the case that an effect has intercepted pointer events. If the KWin operation mode is not X11 only, the window for intercepting the mouse events is no longer created.
2013-06-26 09:40:30 +00:00
static QEvent::Type buttonStateToEvent(PointerButtonState state);
static Qt::MouseButton buttonToQtMouseButton(uint32_t button);
Use Logind to open/close devices needed by libinput With libinput we have the problem that we need to have privileges to open the device files. In order to not need wrappers or suid bits, we use logind. This means that kwin_wayland has to be the session controler. A LogindIntegration is added to connect to logind and wrap the dbus calls. This is based on the logind integration done for ksld in ksmserver. The LogindIntegration is started by Workspace and the InputRedirection tries to become the session controller and starts the libinput integration only after this succeeded.
2014-08-15 07:30:08 +00:00
void setupLibInput();
Ensure screens are created before fully setting up libinput Parts rely on screens being available but input might be created before screens are available. Thus connect to signal and delay.
2015-03-30 06:55:41 +00:00
void setupLibInputWithScreens();
Add sanity checks before updating pointer position and on screen changes We don't want the cursor to leave the visible area, so better check that the cursor doesn't leave it. And when the screens changes better check that the cursor is still on a visible screen. If not: put it back to the center of the closest screen.
2014-10-17 13:44:12 +00:00
void updatePointerPosition(const QPointF &pos);
void updatePointerAfterScreenChange();
Update x11Time when a global shortcut is pressed KGlobalAccel sets the timestamp as a property and we need to set our x11Time to it otherwise following keyboard grabs might fail. Requires 61e2a156678eef033b2629f7c72530dc78d7c3ac in kglobalaccel.
2015-02-19 09:38:49 +00:00
void registerShortcutForGlobalAccelTimestamp(QAction *action);
[wayland] Pass pointer input events to SeatInterface Pointer events are no longer sent through the methods on Toplevel, but properly sent through the SeatInterface. This has the advantage that SeatInterface properly tracks which is the focused pointer surface and does not need to use the xtest extension.
2015-02-26 14:32:44 +00:00
void updateFocusedPointerPosition();
[wayland] Add support for processing touch events InputRedirection gains basic support for processing touch events which are delegated to KWayland::Server. WaylandBackend accepts touch events from KWayland::Client and delegates them to the InputRedirection.
2015-03-25 13:50:14 +00:00
void updateFocusedTouchPosition();
Handle interaction with window decoration directly in InputRedirection So far input events were sent through Xwayland which is not needed as we have all information available. Even more it had the pointer surface on the wrong window when interacting with decorations as it was on the window and not on the decoration.
2015-06-03 16:09:54 +00:00
void updatePointerDecoration(Toplevel *t);
[wayland] Handle pointer events for internal windows If there is a visible internal window it gets the pointer events. The assumption is that the last created internal window is the top most in stacking order.
2015-06-06 01:26:24 +00:00
void updatePointerInternalWindow();
void pointerInternalWindowVisibilityChanged(bool visible);
[wayland] Update cursor image from current decoration
2015-06-04 20:16:30 +00:00
void installCursorFromDecoration();
Don't update focused pointer window on pointer movement while button is pressed If a button is pressed all mouse events should go to the current surface regardless of whether the pointer is on top of it or not.
2015-06-03 15:56:59 +00:00
bool areButtonsPressed() const;
[wayland] Change keyboard focus window when active window changes We used to change it only on keypresses. This resulted in the strange situation that e.g. the input method virtual keyboard doesn't show up until one presses a real key, because e.g. maliit only activates the keyboard if there is an active focus object in the Qt application.
2015-06-13 15:54:08 +00:00
void setupWorkspace();
[wayland] Configure key repeat We take the configuration from the kcminputrc config file, group keyboard (see plasma-desktop.git/kcms/keyboard/kcmmisc.cpp) The values are only used for libinput. For backends providing input events we expect to get repeated key events anyway.
2015-09-15 08:29:06 +00:00
void reconfigure();
Refactor input event handling to be based on filters 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.
2016-02-03 14:17:49 +00:00
void setupInputFilters();
void installInputEventFilter(InputEventFilter *filter);
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
QPointF m_globalPointer;
QHash<uint32_t, PointerButtonState> m_pointerButtons;
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
QScopedPointer<Xkb> m_xkb;
Redirect pointer events to the Toplevel InputRedirection keeps track of the Toplevel which is currently the one which should get pointer events. This is determined by checking whether there is an Unmanaged or a Client at the pointer position. At the moment this is still slightly incorrect, e.g. pointer grabs are ignored, unmanaged are not checked whether they are output only and input shapes are not yet tracked. The pointer events are delivered to the Toplevel as: * enter * leave * move * button press * axis event Nevertheless move events are still generated in InputRedirection through xcb test for simplicity. They are still send to the root window, so all windows get mouse move. Button press and axis are generated only in the implementations of the event handlers and delivered directly to the window, so other windows won't see it.
2013-07-01 06:37:59 +00:00
/**
* @brief The Toplevel which currently receives pointer events
*/
QWeakPointer<Toplevel> m_pointerWindow;
Handle interaction with window decoration directly in InputRedirection So far input events were sent through Xwayland which is not needed as we have all information available. Even more it had the pointer surface on the wrong window when interacting with decorations as it was on the window and not on the decoration.
2015-06-03 16:09:54 +00:00
/**
* @brief The Decoration which currently receives pointer events.
* Decoration belongs to the pointerWindow
**/
QPointer<Decoration::DecoratedClientImpl> m_pointerDecoration;
[wayland] Handle pointer events for internal windows If there is a visible internal window it gets the pointer events. The assumption is that the last created internal window is the top most in stacking order.
2015-06-06 01:26:24 +00:00
QPointer<QWindow> m_pointerInternalWindow;
[wayland] Add support for processing touch events InputRedirection gains basic support for processing touch events which are delegated to KWayland::Server. WaylandBackend accepts touch events from KWayland::Client and delegates them to the InputRedirection.
2015-03-25 13:50:14 +00:00
/**
* @brief The Toplevel which currently receives touch events
*/
QWeakPointer<Toplevel> m_touchWindow;
/**
* external/kwayland
**/
QHash<qint32, qint32> m_touchIdMapper;
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
Beginning of global shortcut handling inside KWin A new GlobalShortcutsManager is introduced which is responsible for holding the registered shortcuts and triggering the matching action. The InputRedirection checks with the GlobalShortcutManager whether a key press event triggers a global shortcut and stops processing the event in that case. At the moment the GlobalShortcutsManager only supports the very basics for KWin internal usage. External applications can not yet make usage of the global shortcut system inside KWin.
2013-07-10 09:41:16 +00:00
GlobalShortcutsManager *m_shortcuts;
Ensure screens are created before fully setting up libinput Parts rely on screens being available but input might be created before screens are available. Thus connect to signal and delay.
2015-03-30 06:55:41 +00:00
LibInput::Connection *m_libInput = nullptr;
[wayland] Add support for pointer warping in InputRedirectionCursor With libinput we do can support warping pointers, let's do it.
2015-06-05 04:43:12 +00:00
bool m_pointerWarping = false;
Refactor input event handling to be based on filters 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.
2016-02-03 14:17:49 +00:00
QVector<InputEventFilter*> m_filters;
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
KWIN_SINGLETON(InputRedirection)
friend InputRedirection *input();
Refactor input event handling to be based on filters 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.
2016-02-03 14:17:49 +00:00
friend class DecorationEventFilter;
friend class InternalWindowEventFilter;
friend class ForwardInputFilter;
};
/**
* Base class for filtering input events inside InputRedirection.
*
* The idea behind the InputEventFilter is to have task oriented
* filters. E.g. there is one filter taking care of a locked screen,
* one to take care of interacting with window decorations, etc.
*
* A concrete subclass can reimplement the virtual methods and decide
* whether an event should be filtered out or not by returning either
* @c true or @c false. E.g. the lock screen filter can easily ensure
* that all events are filtered out.
*
* As soon as a filter returns @c true the processing is stopped. If
* a filter returns @c false the next one is invoked. This means a filter
* installed early gets to see more events than a filter installed later on.
*
* Deleting an instance of InputEventFilter automatically uninstalls it from
* InputRedirection.
**/
class InputEventFilter
{
public:
InputEventFilter();
virtual ~InputEventFilter();
/**
* Event filter for pointer events which can be described by a QMouseEvent.
*
* Please note that the button translation in QMouseEvent cannot cover all
* possible buttons. Because of that also the @p nativeButton code is passed
* through the filter. For internal areas it's fine to use @p event, but for
* passing to client windows the @p nativeButton should be used.
*
* @param event The event information about the move or button press/release
* @param nativeButton The native key code of the button, for move events 0
* @return @c true to stop further event processing, @c false to pass to next filter
**/
virtual bool pointerEvent(QMouseEvent *event, quint32 nativeButton);
/**
* Event filter for pointer axis events.
*
* @param event The event information about the axis event
* @return @c true to stop further event processing, @c false to pass to next filter
**/
virtual bool wheelEvent(QWheelEvent *event);
/**
* Event filter for keyboard events.
*
* @param event The event information about the key event
* @return @c tru to stop further event processing, @c false to pass to next filter.
**/
virtual bool keyEvent(QKeyEvent *event);
virtual bool touchDown(quint32 id, const QPointF &pos, quint32 time);
virtual bool touchMotion(quint32 id, const QPointF &pos, quint32 time);
virtual bool touchUp(quint32 id, quint32 time);
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
};
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
class Xkb
{
public:
[wayland] Pass xkb keymap to Wayland server When creating a new xkb keymap we need to pass it to the Wayland server's seat. As the Wayland protocol expects the keymap as a file descriptor, a temporary file is created, mmapped and the keymap written into it. As the Wayland protocol doesn't restrict how long the file descriptor needs to be valid we keep any created temporary file around till the InputRedirection gets destroyed.
2015-05-28 08:17:41 +00:00
Xkb(InputRedirection *input);
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
~Xkb();
void installKeymap(int fd, uint32_t size);
void updateModifiers(uint32_t modsDepressed, uint32_t modsLatched, uint32_t modsLocked, uint32_t group);
void updateKey(uint32_t key, InputRedirection::KeyboardKeyState state);
xkb_keysym_t toKeysym(uint32_t key);
QString toString(xkb_keysym_t keysym);
Qt::Key toQtKey(xkb_keysym_t keysym);
Qt::KeyboardModifiers modifiers() const;
[wayland] Announce modifier changes to clients
2015-07-13 12:25:09 +00:00
quint32 getMods(quint32 components);
quint32 getGroup();
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
private:
[input] Set a default xkb modifier map
2015-03-27 13:12:41 +00:00
void updateKeymap(xkb_keymap *keymap);
[wayland] Pass xkb keymap to Wayland server When creating a new xkb keymap we need to pass it to the Wayland server's seat. As the Wayland protocol expects the keymap as a file descriptor, a temporary file is created, mmapped and the keymap written into it. As the Wayland protocol doesn't restrict how long the file descriptor needs to be valid we keep any created temporary file around till the InputRedirection gets destroyed.
2015-05-28 08:17:41 +00:00
void createKeymapFile();
[input] Try updating the modifiers after each key press TODO: send new modifier information to wayland server.
2015-03-27 13:15:25 +00:00
void updateModifiers();
[wayland] Pass xkb keymap to Wayland server When creating a new xkb keymap we need to pass it to the Wayland server's seat. As the Wayland protocol expects the keymap as a file descriptor, a temporary file is created, mmapped and the keymap written into it. As the Wayland protocol doesn't restrict how long the file descriptor needs to be valid we keep any created temporary file around till the InputRedirection gets destroyed.
2015-05-28 08:17:41 +00:00
InputRedirection *m_input;
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
xkb_context *m_context;
xkb_keymap *m_keymap;
xkb_state *m_state;
xkb_mod_index_t m_shiftModifier;
xkb_mod_index_t m_controlModifier;
xkb_mod_index_t m_altModifier;
xkb_mod_index_t m_metaModifier;
Qt::KeyboardModifiers m_modifiers;
Add support for modifier only shortcuts on Wayland On popular demand! This change tracks how modifiers are used and detects a modifier only key press/release. That is: * no other key is pressed when the modifier gets pressed * no other key gets pressed before the modifier gets released If such a press/release is detected, we call a configurable dbus call. The possible shortcuts can be configured in kwinrc, group "ModifierOnlyShortcuts". The following keys are supported: * Shift * Control * Alt * Meta As value it takes a QStringList (comma seperated string) with service,path,interface,method,additionalargs E.g. to invoke Desktop Grid effect on Meta key: [ModifierOnlyShortcuts] Meta=org.kde.kglobalaccel,/component/kwin/,org.kde.kglobalaccel.Component,invokeShortcut,ShowDesktopGrid I do not intend to add a config interface for it. Let's keep it a hidden way. REVIEW: 124954
2015-08-27 15:56:28 +00:00
struct {
uint pressCount = 0;
Qt::KeyboardModifier modifier = Qt::NoModifier;
} m_modOnlyShortcut;
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
};
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
inline
InputRedirection *input()
{
return InputRedirection::s_self;
}
inline
const QPointF &InputRedirection::globalPointer() const
{
return m_globalPointer;
}
inline
InputRedirection::PointerButtonState InputRedirection::pointerButtonState(uint32_t button) const
{
auto it = m_pointerButtons.constFind(button);
if (it != m_pointerButtons.constEnd()) {
return it.value();
} else {
return KWin::InputRedirection::PointerButtonReleased;
}
}
Update x11Time when a global shortcut is pressed KGlobalAccel sets the timestamp as a property and we need to set our x11Time to it otherwise following keyboard grabs might fail. Requires 61e2a156678eef033b2629f7c72530dc78d7c3ac in kglobalaccel.
2015-02-19 09:38:49 +00:00
template <typename T>
inline
void InputRedirection::registerShortcut(const QKeySequence &shortcut, QAction *action, T *receiver, void (T::*slot)()) {
registerShortcut(shortcut, action);
connect(action, &QAction::triggered, receiver, slot);
}
InputRedirection for keyboard events Major new functionality is xkbcommon support. InputRedirection holds an instance to a small wrapper class which has the xkb context, keymap and state. The keymap is initialied from the file descriptor we get from the Wayland backend. InputRedirection uses this to translate the keycodes into keysymbols and to QString and to track the modifiers as provided by the Qt::KeybordModifiers flags. This provides us enough information for internal usage (e.g. pass through effects if they have "grabbed" the keyboard). If KWin doesn't filter out the key events, it passes them on to the currently active Client respectively an unmanaged on top of the stack. This needs still some improvement (not each unmanaged should get the event). The Client/Unmnaged still uses xtest extension to send the key events to the window. So keylogging is still possible.
2013-07-02 09:44:18 +00:00
inline
Qt::KeyboardModifiers Xkb::modifiers() const
{
return m_modifiers;
}
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
} // namespace KWin
[libinput] Make signals queueable * Declare and register enums as metatypes * quint32 instead of uint32_t
2015-09-02 08:10:49 +00:00
Q_DECLARE_METATYPE(KWin::InputRedirection::KeyboardKeyState)
Q_DECLARE_METATYPE(KWin::InputRedirection::PointerButtonState)
Q_DECLARE_METATYPE(KWin::InputRedirection::PointerAxis)
Introduce the beginning of an InputRedirection class So far this new class is not yet doing much. The WaylandBackend forwards the received pointer events to this InputRedirection class. From there signals are emitted to inform internal areas about the changes first. The events are currently forwarded to X through the xtest extension. This will be removed in future. Input will be forwarded directly to the surface which wants it (no matter whether X11 or Wayland).
2013-06-26 08:15:20 +00:00
#endif // KWIN_INPUT_H
Reference in a new issue Copy permalink