Get Capslock state on Linux with Wayland - c++

Question

I am struggling with the following task: for our cross-platform application I want to enable a capslock warning for the user. This works perfectly on Windows and macOS and is a bit unnecessarily complicated but doable on Linux with X11, though I cannot find out how to do it properly on Wayland.
We are using Qt5, so the more Qt APIs I can use for this, the better. I see that Qt has a very extensive Wayland framework, but it seems to be designed primarily for writing your own compositor and not for accessing specifics of the underlying platform plugin.
Here's the code as far as I have it:
#include <QGuiApplication>
#include <qpa/qplatformnativeinterface.h>
// namespace required to avoid name clashes with declarations in XKBlib.h
namespace X11
{
#include <X11/XKBlib.h>
}
void checkCapslockState()
{
// ... Windows and macOS one-liners
// Here starts the Linux mess.
// At least I can query the display with this for both X11 and Wayland.
QPlatformNativeInterface* native = QGuiApplication::platformNativeInterface();
auto* display = native->nativeResourceForWindow("display", nullptr);
if (!display) {
return;
}
const QString platform = QGuiApplication::platformName();
if (platform == "xcb") {
unsigned state = 0;
if (X11::XkbGetIndicatorState(reinterpret_cast<X11::Display*>(display), XkbUseCoreKbd, &state) == Success) {
// works fine
newCapslockState = ((state & 1u) != 0);
}
} else if (platform == "wayland") {
// but how to proceed here?
// struct wl_display* waylandDisplay = reinterpret_cast<struct wl_display*>(display);
}
// ...
}
My understanding is that I have to get hold of the Wayland wl_seat object somehow, which holds information about the wl_keyboard. However, I cannot find a way to access these objects from the wl_display object alone without instantiating all sorts of contexts. The Qt application itself is already running as a Wayland client, so there should be a way to access these objects, I would assume. Unfortunately, the Wayland documentation on this is very sparse and quite opaque for someone not familiar with the whole architecture and Wayland's user base is still too small that things pop up on Google.

Answer 1

I found a solution, but I am far from satisfied with it.
I am using KWayland here, but it is possible to use the plain Wayland C API, of course. Be prepared to write 200-300 additional lines of boilerplate code, though. KWayland abstracts that a bit, but it is still pretty verbose. Even the X11 solution is shorter, let alone the one-liners of Windows and macOS.
I don't think this is a state in which Wayland will be pretty successful in the long-term. It's okay to have that much control on the lowest level, but there need to be proper high-level abstractions in place.
Long story short, here's the full code for all platforms:
#include <QGuiApplication>
#if defined(Q_OS_WIN)
#include <windows.h>
#elif defined(Q_OS_MACOS)
#include <CoreGraphics/CGEventSource.h>
#elif defined(Q_OS_UNIX)
#include <qpa/qplatformnativeinterface.h>
// namespace required to avoid name clashes with declarations in XKBlib.h
namespace X11
{
#include <X11/XKBlib.h>
}
#include <KF5/KWayland/Client/registry.h>
#include <KF5/KWayland/Client/seat.h>
#include <KF5/KWayland/Client/keyboard.h>
#endif
void MyCls::checkCapslockState()
{
const QString platform = QGuiApplication::platformName();
#if defined(Q_OS_WIN)
newCapslockState = (GetKeyState(VK_CAPITAL) == 1);
#elif defined(Q_OS_MACOS)
newCapslockState = ((CGEventSourceFlagsState(kCGEventSourceStateHIDSystemState) & kCGEventFlagMaskAlphaShift) != 0);
#elif defined(Q_OS_UNIX)
// get platform display
QPlatformNativeInterface* native = QGuiApplication::platformNativeInterface();
auto* display = native->nativeResourceForWindow("display", nullptr);
if (!display) {
return;
}
if (platform == "xcb") {
unsigned state = 0;
if (X11::XkbGetIndicatorState(reinterpret_cast<X11::Display*>(display), XkbUseCoreKbd, &state) == Success) {
newCapslockState = ((state & 1u) != 0);
}
} else if (platform == "wayland") {
if (!m_wlRegistry) {
auto* wlDisplay = reinterpret_cast<struct wl_display*>(display);
m_wlRegistry.reset(new KWayland::Client::Registry());
m_wlRegistry->create(wlDisplay);
m_wlRegistry->setup();
// wait for a seat to be announced
connect(m_wlRegistry.data(), &KWayland::Client::Registry::seatAnnounced, [this](quint32 name, quint32 version) {
auto* wlSeat = new KWayland::Client::Seat(m_wlRegistry.data());
wlSeat->setup(m_wlRegistry->bindSeat(name, version));
// wait for a keyboard to become available in the seat
connect(wlSeat, &KWayland::Client::Seat::hasKeyboardChanged, [wlSeat, this](bool hasKeyboard) {
if (hasKeyboard) {
auto* keyboard = wlSeat->createKeyboard(wlSeat);
// listen for a modifier change
connect(keyboard, &KWayland::Client::Keyboard::modifiersChanged,
[this](quint32 depressed, quint32 latched, quint32 locked, quint32 group) {
Q_UNUSED(depressed)
Q_UNUSED(latched)
Q_UNUSED(group)
newCapslockState = (locked & 2u) != 0;
// emit signals etc. here to notify outer non-callback
// context of the new value of newCapslockState
});
}
});
});
}
}
// do something with the newCapslockState state for any
// platform other than Wayland
}
m_wlRegistry is defined as a QScopedPointer<KWayland::Client::Registry> member in the header file.
This solution basically works, but suffers from either a bug in KWin or a weirdness of the protocol (I don't know which). Pressing the Capslock key will trigger the inner lambda callback twice: first time with bit 2 in locked set and a second time on key release with it unset. There is no reliable way of filtering out this second activation based on the other parameters passed (I tried ignoring when depressed != 0, but it's not working as expected). Pressing any other key after that will trigger the callback a third time with the bit set again. So when you are actually typing, the code works, but when you are just pressing Capslock, the behaviour is weird and less reliable than the solutions for other platforms. Since the Capslock indicator in the Plasma tray has the same issue, I would assume this is a bug.
As a KDE-specific solution, there appears to be another interface one could listen to called org_kde_kwin_keystate (https://github.com/KDE/kwayland/blob/master/src/client/protocols/keystate.xml). However, when I was testing it in a KDE Neon VM, the compositor did not announce this protocol extension, so I was unable to use it.