kwin/xkb.h

166 lines
4.1 KiB
C
Raw Permalink Normal View History

2020-08-03 01:22:19 +03:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-03 01:22:19 +03:00
SPDX-FileCopyrightText: 2013, 2016, 2017 Martin Gräßlin <mgraesslin@kde.org>
2020-08-03 01:22:19 +03:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#ifndef KWIN_XKB_H
#define KWIN_XKB_H
#include "input.h"
#include <kwin_export.h>
#include <KSharedConfig>
#include <QLoggingCategory>
Q_DECLARE_LOGGING_CATEGORY(KWIN_XKB)
struct xkb_context;
struct xkb_keymap;
struct xkb_state;
struct xkb_compose_table;
struct xkb_compose_state;
typedef uint32_t xkb_mod_index_t;
typedef uint32_t xkb_led_index_t;
typedef uint32_t xkb_keysym_t;
typedef uint32_t xkb_layout_index_t;
namespace KWaylandServer
{
class SeatInterface;
}
namespace KWin
{
class KWIN_EXPORT Xkb : public QObject
{
Q_OBJECT
public:
Xkb(QObject *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 19:52:26 +03:00
~Xkb() override;
void setConfig(KSharedConfigPtr config) {
m_config = std::move(config);
}
void setNumLockConfig(KSharedConfigPtr config) {
m_numLockConfig = std::move(config);
}
void reconfigure();
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);
xkb_keysym_t currentKeysym() const {
return m_keysym;
}
QString toString(xkb_keysym_t keysym);
Qt::Key toQtKey(xkb_keysym_t keysym) const;
xkb_keysym_t fromQtKey(Qt::Key key, Qt::KeyboardModifiers mods) const;
xkb_keysym_t fromKeyEvent(QKeyEvent *event) const;
Qt::KeyboardModifiers modifiers() const;
Qt::KeyboardModifiers modifiersRelevantForGlobalShortcuts() const;
bool shouldKeyRepeat(quint32 key) const;
void switchToNextLayout();
void switchToPreviousLayout();
void switchToLayout(xkb_layout_index_t layout);
enum class LED {
NumLock = 1 << 0,
CapsLock = 1 << 1,
ScrollLock = 1 << 2
};
Q_DECLARE_FLAGS(LEDs, LED)
LEDs leds() const {
return m_leds;
}
xkb_keymap *keymap() const {
return m_keymap;
}
xkb_state *state() const {
return m_state;
}
quint32 currentLayout() const {
return m_currentLayout;
}
QString layoutName() const;
QMap<xkb_layout_index_t, QString> layoutNames() const;
quint32 numberOfLayouts() const;
Handle modifier updates in the same sequence as Wayland does Summary: Consider the case that capslock gets pressed and released. In the case of Weston we have a sequence of: 1. Key press event 2. Modifier changed event 3. Key release event 4. Modifier changed event KWin however used to send the events in the following sequence: 1. Modifier changed event (on key press) 2. Key press event 3. Modifier changed event (on key release) 4. Key release event It looks like Xwayland is not able to properly process the sequence sent by KWin. And in fact KWin's sequence is wrong as it sends a state which does not match. We report that the caps lock is pressed in the modifiers prior to the application getting informed about the key press of caps lock. This change aligns KWin's implementation to the behavior of Weston. The main difference is that when modifiers change Xkb internally caches the serialized modifier states. And KeyboardInputRedirection just forwards the modifiers to KWayland::Server::SeatInterface once the processing has finished. SeatInterface ignores the forwarding if no states changes, so it is fine to do it that way. BUG: 377155 Test Plan: Not yet tested with an affected Xwayland as I only have 1.18 and the problem started with 1.19. But verified the sequence of events with WAYLAND_DEBUG and caps lock stil working in QtWayland clients and Xwayland 1.18 Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5452
2017-04-14 22:01:20 +03:00
/**
* Forwards the current modifier state to the Wayland seat
*/
Handle modifier updates in the same sequence as Wayland does Summary: Consider the case that capslock gets pressed and released. In the case of Weston we have a sequence of: 1. Key press event 2. Modifier changed event 3. Key release event 4. Modifier changed event KWin however used to send the events in the following sequence: 1. Modifier changed event (on key press) 2. Key press event 3. Modifier changed event (on key release) 4. Key release event It looks like Xwayland is not able to properly process the sequence sent by KWin. And in fact KWin's sequence is wrong as it sends a state which does not match. We report that the caps lock is pressed in the modifiers prior to the application getting informed about the key press of caps lock. This change aligns KWin's implementation to the behavior of Weston. The main difference is that when modifiers change Xkb internally caches the serialized modifier states. And KeyboardInputRedirection just forwards the modifiers to KWayland::Server::SeatInterface once the processing has finished. SeatInterface ignores the forwarding if no states changes, so it is fine to do it that way. BUG: 377155 Test Plan: Not yet tested with an affected Xwayland as I only have 1.18 and the problem started with 1.19. But verified the sequence of events with WAYLAND_DEBUG and caps lock stil working in QtWayland clients and Xwayland 1.18 Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5452
2017-04-14 22:01:20 +03:00
void forwardModifiers();
void setSeat(KWaylandServer::SeatInterface *seat);
Q_SIGNALS:
void ledsChanged(const LEDs &leds);
private:
xkb_keymap *loadKeymapFromConfig();
xkb_keymap *loadDefaultKeymap();
void updateKeymap(xkb_keymap *keymap);
void createKeymapFile();
void updateModifiers();
void updateConsumedModifiers(uint32_t key);
QString layoutName(xkb_layout_index_t layout) const;
xkb_context *m_context;
xkb_keymap *m_keymap;
xkb_state *m_state;
xkb_mod_index_t m_shiftModifier;
xkb_mod_index_t m_capsModifier;
xkb_mod_index_t m_controlModifier;
xkb_mod_index_t m_altModifier;
xkb_mod_index_t m_metaModifier;
xkb_mod_index_t m_numModifier;
xkb_led_index_t m_numLock;
xkb_led_index_t m_capsLock;
xkb_led_index_t m_scrollLock;
Qt::KeyboardModifiers m_modifiers;
Qt::KeyboardModifiers m_consumedModifiers;
xkb_keysym_t m_keysym;
quint32 m_currentLayout = 0;
struct {
xkb_compose_table *table = nullptr;
xkb_compose_state *state = nullptr;
} m_compose;
LEDs m_leds;
KSharedConfigPtr m_config;
KSharedConfigPtr m_numLockConfig;
Handle modifier updates in the same sequence as Wayland does Summary: Consider the case that capslock gets pressed and released. In the case of Weston we have a sequence of: 1. Key press event 2. Modifier changed event 3. Key release event 4. Modifier changed event KWin however used to send the events in the following sequence: 1. Modifier changed event (on key press) 2. Key press event 3. Modifier changed event (on key release) 4. Key release event It looks like Xwayland is not able to properly process the sequence sent by KWin. And in fact KWin's sequence is wrong as it sends a state which does not match. We report that the caps lock is pressed in the modifiers prior to the application getting informed about the key press of caps lock. This change aligns KWin's implementation to the behavior of Weston. The main difference is that when modifiers change Xkb internally caches the serialized modifier states. And KeyboardInputRedirection just forwards the modifiers to KWayland::Server::SeatInterface once the processing has finished. SeatInterface ignores the forwarding if no states changes, so it is fine to do it that way. BUG: 377155 Test Plan: Not yet tested with an affected Xwayland as I only have 1.18 and the problem started with 1.19. But verified the sequence of events with WAYLAND_DEBUG and caps lock stil working in QtWayland clients and Xwayland 1.18 Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5452
2017-04-14 22:01:20 +03:00
struct {
xkb_mod_index_t depressed = 0;
xkb_mod_index_t latched = 0;
xkb_mod_index_t locked = 0;
} m_modifierState;
enum class Ownership {
Server,
Client
};
Ownership m_ownership = Ownership::Server;
QPointer<KWaylandServer::SeatInterface> m_seat;
};
inline
Qt::KeyboardModifiers Xkb::modifiers() const
{
return m_modifiers;
}
}
Q_DECLARE_METATYPE(KWin::Xkb::LED)
Q_DECLARE_METATYPE(KWin::Xkb::LEDs)
#endif