kwin/src/xkb.h

170 lines
4.1 KiB
C
Raw Normal View History

2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2013, 2016, 2017 Martin Gräßlin <mgraesslin@kde.org>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#ifndef KWIN_XKB_H
#define KWIN_XKB_H
#include "input.h"
#include <xkbcommon/xkbcommon.h>
#include <kwin_export.h>
#include <KConfigGroup>
#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 16:52:26 +00:00
~Xkb() override;
void setConfig(const KSharedConfigPtr &config);
void setNumLockConfig(const KSharedConfigPtr &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,
uint32_t scanCode = 0,
Qt::KeyboardModifiers modifiers = Qt::KeyboardModifiers(),
bool superAsMeta = false) const;
Qt::KeyboardModifiers modifiers() const;
Qt::KeyboardModifiers modifiersRelevantForGlobalShortcuts(uint32_t scanCode = 0) const;
bool shouldKeyRepeat(quint32 key) const;
void switchToNextLayout();
void switchToPreviousLayout();
bool switchToLayout(xkb_layout_index_t layout);
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;
}
const auto &modifierState() const
{
return m_modifierState;
}
QString layoutName(xkb_layout_index_t index) const;
QString layoutName() const;
QString layoutShortName(int index) 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 19:01:20 +00: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 19:01:20 +00:00
void forwardModifiers();
void setSeat(KWaylandServer::SeatInterface *seat);
QByteArray keymapContents() const;
Q_SIGNALS:
void ledsChanged(const LEDs &leds);
void modifierStateChanged();
private:
void applyEnvironmentRules(xkb_rule_names &);
xkb_keymap *loadKeymapFromConfig();
xkb_keymap *loadDefaultKeymap();
void updateKeymap(xkb_keymap *keymap);
void createKeymapFile();
void updateModifiers();
void updateConsumedModifiers(uint32_t key);
xkb_context *m_context;
xkb_keymap *m_keymap;
QStringList m_layoutList;
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;
KConfigGroup m_configGroup;
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 19:01:20 +00:00
struct
{
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 19:01:20 +00:00
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;
}
}
#endif