kwin/pointer_input.h

260 lines
7.6 KiB
C
Raw Normal View History

/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2013, 2016 Martin Gräßlin <mgraesslin@kde.org>
Copyright (C) 2018 Roman Gilg <subdiff@gmail.com>
Copyright (C) 2019 Vlad Zagorodniy <vladzzag@gmail.com>
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_POINTER_INPUT_H
#define KWIN_POINTER_INPUT_H
#include "input.h"
#include <QElapsedTimer>
#include <QObject>
#include <QPointer>
#include <QPointF>
class QWindow;
Warp the xcb pointer whenever pointer leaves an X11 surface Summary: For Xwayland windows we observed that passing pointer focus to another window does not trigger proper leave events on X. Which results in e.g. tooltip windows to show after the pointer moved to a completely different position on a completely different surface. This is a bug in Xwayland which will be fixed in 1.19 (already fixed in master). Given that there is a runtime version check. Although it's fixed in Xwayland master it's worth to carry a workaround. To circumvent this problem KWin warps the xcb pointer to 0/0 whever an X window loses pointer focus. That way the X window gets a proper leave through the X protocol. This created a problem though: when giving focus back to the X window it started to warp the pointer for maximized windows as KWin got pointer motion events through the X11 event filter for positions on the window decoration. These are passed into the screen edge filter which pushes the pointer back and warps our Wayland pointer. To solve this problem KWin no longer performs any actions for pointer motion in the X11 event filter if not on X11. The event filter needs to be reworked and most of it should be moved into the Platform API, if possible. Test Plan: Reproduced situations where one could see that pointer updates don't trigger leave. E.g. going from a highlighted window to the decoration. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2531
2016-08-22 17:20:57 +00:00
namespace KWayland
{
namespace Server
{
class SurfaceInterface;
}
}
namespace KWin
{
class CursorImage;
class InputRedirection;
class Toplevel;
class WaylandCursorTheme;
class CursorShape;
namespace Decoration
{
class DecoratedClientImpl;
}
namespace LibInput
{
class Device;
}
class KWIN_EXPORT PointerInputRedirection : public InputDeviceHandler
{
Q_OBJECT
public:
explicit PointerInputRedirection(InputRedirection *parent);
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~PointerInputRedirection() override;
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
void init() override;
void updateAfterScreenChange();
bool supportsWarping() const;
void warp(const QPointF &pos);
QPointF pos() const {
return m_pos;
}
Qt::MouseButtons buttons() const {
return m_qtButtons;
}
bool areButtonsPressed() const;
QImage cursorImage() const;
QPoint cursorHotSpot() const;
void markCursorAsRendered();
void setEffectsOverrideCursor(Qt::CursorShape shape);
void removeEffectsOverrideCursor();
void setWindowSelectionCursor(const QByteArray &shape);
void removeWindowSelectionCursor();
void updatePointerConstraints();
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
void setEnableConstraints(bool set);
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
bool isConstrained() const {
return m_confined || m_locked;
}
bool focusUpdatesBlocked() override;
/**
* @internal
*/
void processMotion(const QPointF &pos, uint32_t time, LibInput::Device *device = nullptr);
/**
* @internal
*/
void processMotion(const QPointF &pos, const QSizeF &delta, const QSizeF &deltaNonAccelerated, uint32_t time, quint64 timeUsec, LibInput::Device *device);
/**
* @internal
*/
void processButton(uint32_t button, InputRedirection::PointerButtonState state, uint32_t time, LibInput::Device *device = nullptr);
/**
* @internal
*/
void processAxis(InputRedirection::PointerAxis axis, qreal delta, qint32 discreteDelta, InputRedirection::PointerAxisSource source, uint32_t time, LibInput::Device *device = nullptr);
/**
* @internal
*/
void processSwipeGestureBegin(int fingerCount, quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processSwipeGestureUpdate(const QSizeF &delta, quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processSwipeGestureEnd(quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processSwipeGestureCancelled(quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processPinchGestureBegin(int fingerCount, quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processPinchGestureUpdate(qreal scale, qreal angleDelta, const QSizeF &delta, quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processPinchGestureEnd(quint32 time, KWin::LibInput::Device *device = nullptr);
/**
* @internal
*/
void processPinchGestureCancelled(quint32 time, KWin::LibInput::Device *device = nullptr);
private:
void cleanupInternalWindow(QWindow *old, QWindow *now) override;
void cleanupDecoration(Decoration::DecoratedClientImpl *old, Decoration::DecoratedClientImpl *now) override;
void focusUpdate(Toplevel *focusOld, Toplevel *focusNow) override;
QPointF position() const override;
void updateOnStartMoveResize();
void updateToReset();
void updatePosition(const QPointF &pos);
void updateButton(uint32_t button, InputRedirection::PointerButtonState state);
Warp the xcb pointer whenever pointer leaves an X11 surface Summary: For Xwayland windows we observed that passing pointer focus to another window does not trigger proper leave events on X. Which results in e.g. tooltip windows to show after the pointer moved to a completely different position on a completely different surface. This is a bug in Xwayland which will be fixed in 1.19 (already fixed in master). Given that there is a runtime version check. Although it's fixed in Xwayland master it's worth to carry a workaround. To circumvent this problem KWin warps the xcb pointer to 0/0 whever an X window loses pointer focus. That way the X window gets a proper leave through the X protocol. This created a problem though: when giving focus back to the X window it started to warp the pointer for maximized windows as KWin got pointer motion events through the X11 event filter for positions on the window decoration. These are passed into the screen edge filter which pushes the pointer back and warps our Wayland pointer. To solve this problem KWin no longer performs any actions for pointer motion in the X11 event filter if not on X11. The event filter needs to be reworked and most of it should be moved into the Platform API, if possible. Test Plan: Reproduced situations where one could see that pointer updates don't trigger leave. E.g. going from a highlighted window to the decoration. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2531
2016-08-22 17:20:57 +00:00
void warpXcbOnSurfaceLeft(KWayland::Server::SurfaceInterface *surface);
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
QPointF applyPointerConfinement(const QPointF &pos) const;
void disconnectConfinedPointerRegionConnection();
void disconnectLockedPointerAboutToBeUnboundConnection();
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
void disconnectPointerConstraintsConnection();
void breakPointerConstraints(KWayland::Server::SurfaceInterface *surface);
CursorImage *m_cursor;
bool m_supportsWarping;
QPointF m_pos;
QHash<uint32_t, InputRedirection::PointerButtonState> m_buttons;
Qt::MouseButtons m_qtButtons;
QMetaObject::Connection m_focusGeometryConnection;
QMetaObject::Connection m_internalWindowConnection;
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
QMetaObject::Connection m_constraintsConnection;
QMetaObject::Connection m_constraintsActivatedConnection;
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
QMetaObject::Connection m_confinedPointerRegionConnection;
QMetaObject::Connection m_lockedPointerAboutToBeUnboundConnection;
QMetaObject::Connection m_decorationGeometryConnection;
Implement support for pointer constraints Summary: There are two types of constraints supported: 1. Pointer confinement 2. Pointer locking In the case of confinement the pointer is confined to a given region of the surface. This is comparable to general operation where the pointer is confined to the screen region. In the second case the pointer gets locked. That means it cannot move at all. No further position updates are provided, only relative motion events can go to the application. There is a hint about cursor position update on unlock which is not yet implemented in KWayland::Server, thus also not in this change. The implementation in KWin grants the requests for pointer constraints when the pointer enters the constrained region, either by pointer movement or by e.g. stacking order changes. There is no confirmation from user required to enter that mode. But we want to show an OSD when the pointer gets constrained, this is not yet implemented, though. Breaking an active constraint is relatively easy. E.g. changing the stacking order will break the constraint if another surface is under the cursor. Also (in case of confinement) moving the pointer to an overlapping window breaks the confinement. But as soon as one moves the pointer back to the window a constraint might get honoured again. To properly break there is a dedicated event filter. It listens for a long press of the Escape key. If hold for 3sec the pointer constraint is broken and not activated again till the pointer got moved out of the window. Afterward when moving in the pointer might activate again. The escape filter ensures that the key press is forwarded to the application if it's a short press or if another key gets pressed during the three seconds. If the three seconds way fires, the later escape release is not sent to the application. This basic interaction is also ensured through an added auto test. This change implements T4605. Test Plan: Added auto test and nested KWin Wayland with D3488 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3506
2016-11-25 06:17:43 +00:00
bool m_confined = false;
bool m_locked = false;
bool m_enableConstraints = true;
};
class CursorImage : public QObject
{
Q_OBJECT
public:
explicit CursorImage(PointerInputRedirection *parent = nullptr);
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~CursorImage() override;
void setEffectsOverrideCursor(Qt::CursorShape shape);
void removeEffectsOverrideCursor();
void setWindowSelectionCursor(const QByteArray &shape);
void removeWindowSelectionCursor();
QImage image() const;
QPoint hotSpot() const;
void markAsRendered();
Q_SIGNALS:
void changed();
private:
void reevaluteSource();
void update();
void updateServerCursor();
void updateDecoration();
void updateDecorationCursor();
void updateMoveResize();
void updateDrag();
void updateDragCursor();
void loadTheme();
struct Image {
QImage image;
QPoint hotSpot;
};
void loadThemeCursor(CursorShape shape, Image *image);
void loadThemeCursor(const QByteArray &shape, Image *image);
template <typename T>
void loadThemeCursor(const T &shape, QHash<T, Image> &cursors, Image *image);
enum class CursorSource {
LockScreen,
EffectsOverride,
MoveResize,
PointerSurface,
Decoration,
DragAndDrop,
Fallback,
WindowSelector
};
void setSource(CursorSource source);
PointerInputRedirection *m_pointer;
CursorSource m_currentSource = CursorSource::Fallback;
WaylandCursorTheme *m_cursorTheme = nullptr;
struct {
QMetaObject::Connection connection;
QImage image;
QPoint hotSpot;
} m_serverCursor;
Image m_effectsCursor;
Image m_decorationCursor;
QMetaObject::Connection m_decorationConnection;
Image m_fallbackCursor;
Image m_moveResizeCursor;
Image m_windowSelectionCursor;
QHash<CursorShape, Image> m_cursors;
QHash<QByteArray, Image> m_cursorsByName;
QElapsedTimer m_surfaceRenderedTimer;
struct {
Image cursor;
QMetaObject::Connection connection;
} m_drag;
};
}
#endif