Qt Wayland Tablet News

Vor ein paar Wochen wurde Qt 6.8 veröffentlicht, das viele Korrekturen und Verbesserungen für unsere Software mit sich bringt. Einige davon wurden von mir selbst beigesteuert, und in diesem Beitrag möchte ich einige von ihnen hervorheben.
Eine Übersetzung von 🇬🇧 Nicolas Fella 

Sie beziehen sich auf die Grafiktablett-/Stylus-Eingabe auf Wayland. Bevor wir uns mit den Korrekturen beschäftigen, wollen wir einen kurzen Überblick über den Ablauf von Tablet-Eingabeereignissen auf Wayland geben:

Die Eingabeereignisse entstehen im Kernel-Treiber für das jeweilige Tablet, der mit der Hardware (über USB, Bluetooth usw.) kommuniziert. Der Kernel gibt Ereignisse über das evdev-System an den Benutzerbereich weiter. Auf der Userspace-Seite liest ein Wayland-Compositor diese Ereignisse. Die meisten Compositors nutzen hierfür libinput, eine Bibliothek, die rohe evdev-Ereignisse in etwas umwandelt, das für den Compositor besser nutzbar ist, und dabei einige Bereinigungen und Konfigurationen vornimmt. Der Compositor liefert dann Ereignisse an native Wayland-Anwendungen unter Verwendung des tablet-v2-Protokolls. Für ältere XWayland-Anwendungen verwendet der Compositor dieses Protokoll, um Ereignisse an XWayland zu senden, das sie in Dinge übersetzt, die X11-Anwendungen verstehen. Der Compositor kann nützliche Transformationen auf die Eingaben anwenden, z. B. welcher Bereich des Bildschirms dem Tablett zugeordnet ist, die Druckkurve des Stifts ändern oder Schaltflächen mit Tastaturkürzeln verbinden.

Die Anwendung verarbeitet dann die Ereignisse, wobei sie möglicherweise ein UI-Toolkit wie Qt einsetzt. Qt erstellt QTabletEvent-Objekte für eingehende Wayland-Ereignisse und gibt diese an alle UI-Elemente weiter. Falls kein UI-Element auf das Ereignis reagiert, synthetisiert Qt ein Maus-Ereignis aus dem Tablet-Ereignis und gibt dieses an die UI-Elemente weiter. Auf diese Weise benötigen die meisten Steuerelemente wie Schaltflächen und Menüs keinen speziellen Code, um Tablet-Eingaben zu verarbeiten. Nur bei der Verarbeitung von Eingaben auf sehr niedriger Ebene oder wenn tablet-spezifische Interaktionen erforderlich sind (z. B. Reaktion auf unterschiedliche Druckwerte), müssen Anwendungsentwickler Tablet-Ereignisse explizit in ihrem Code verarbeiten. Die meisten UI-Toolkits funktionieren ähnlich wie diese. Wenn eine Anwendung überhaupt nicht auf Tablet-Eingaben reagiert, melden Sie bitte einen Fehler in der Anwendung.

Qt Wayland unterstützt die Tablet-Eingabe schon seit einigen Jahren, was genau musste also repariert werden? Der erste Punkt sind die Cursor. In Wayland teilt die Anwendung dem Compositor mit, welchen Cursor er verwenden soll. Dies kann entweder durch Angabe einer Oberfläche (d.h. eines Bildes) oder einer benannten Cursorform geschehen. Raten Sie mal, welche Form Qt verwendet? Das ist richtig: Weder noch. Es wurde einfach überhaupt kein Cursor angegeben. Das Ergebnis hängt vom Compositor ab: KWin zeigt einen Fadenkreuz-Cursor als Fallback an, was ~okay ist, aber nicht der Cursor, den der Anwendungsentwickler wollte. Auf anderen Compositors, die ich getestet habe, ist überhaupt kein Cursor sichtbar, was überhaupt nicht in Ordnung ist. Für Qt 6.8 habe ich die fehlende Cursor-Unterstützung implementiert, so dass Tablets jetzt den gleichen Cursor wie bei der Mauseingabe erhalten (es sei denn, der Anwendungsentwickler möchte natürlich einen anderen Cursor für die Tablet-Eingabe).

Eine weitere Sache, die vor allem Nicht-Plasma-Benutzer betrifft, sind clientseitig dekorierte Fenster. Unter Plasma verwenden Qt-Anwendungen normalerweise die serverseitige Dekoration, die von KWin bereitgestellt wird, aber z.B. unter GNOME ist Qt für das Zeichnen und die Handhabung von Fensterdekorationen verantwortlich. Hierfür bietet Qt ein Plugin-System, so dass verschiedene Dekorationen mit unterschiedlichem Aussehen und Gefühl ausgetauscht werden können. Leider verarbeiteten diese Dekorationen die Tablet-Eingabe überhaupt nicht, so dass es nicht möglich war, Fenster mit einem Tablet-Stift zu bewegen oder zu schließen. Ich habe dies behoben, indem ich den Dekorationen vorgespielt habe, dass die Tabletteingabe eine Mauseingabe ist, was eine einfache, aber effektive Lösung für dieses Problem war. Wenn es jemals einen Bedarf an Dekorationen gibt, die die Tablet-Eingabe anders behandeln als die Maus-Eingabe, können wir dies wieder aufgreifen.

Apropos Fenster verschieben, eine Funktion, die die meisten KDE-Anwendungen haben (auch wenn sie heutzutage standardmäßig deaktiviert ist), ist das Ziehen eines leeren Bereichs, um das Fenster zu verschieben. Dies funktionierte nicht, wenn man einen Stylus verwendete. Und warum? Dazu müssen wir uns ansehen, wie dies auf Wayland-Ebene funktioniert. Das xdg-shell Protokoll (das für die meisten Anwendungsfenster zuständig ist) verfügt über eine Bewegungsanforderung, die den Compositor auffordert, eine Bewegungsinteraktion für das Fenster zu starten. Als Teil der Anforderung muss die Anwendung eine Seriennummer (Serial) übergeben, die dem letzten Eingabeereignis entspricht, das die Anwendung erhalten hat. Um zu vermeiden, dass sich Anwendungen plötzlich im Hintergrund bewegen, erlauben Compositors in der Regel nur Bewegungsanfragen als Ergebnis direkter Benutzereingaben, so dass diese Seriennummer dem letzten Eingabeereignis entsprechen muss. Qt wickelt diese Bewegungsanforderung in die Funktion QWindow::startSystemMove ein. Das Problem war, dass Qt die Seriennummer, die es als Teil der Tabletteingabe erhielt, nicht verfolgte, so dass es beim Starten der Bewegung eine falsche Seriennummer übergab und der Compositor die Bewegung (zu Recht) ablehnte. Ein paar zusätzliche Zeilen später wurde die Serial richtig verfolgt und Verschieben von Fenstern mit einem Stift funktioniert, gerade rechtzeitig für Nate, um die Funktion standardmäßig zu deaktivieren.

Das gleiche Problem betraf auch Drag-and-Drop. Wenn ein Ziehen mit einem Stift gestartet wird, übergibt Qt nun die korrekte Serie, so dass Drag-and-Drop funktioniert (zumindest auf der Qt-Seite, auf der KWin-Seite gibt es derzeit einen Fehler, der dies verhindert).

Der letzte Fix für heute bezieht sich darauf, wie Anwendungen auf die Tablet-Ereignisse reagieren. Manchmal verarbeiten Anwendungen Klicks unterschiedlich, je nachdem, welche Tastaturmodifikatoren gedrückt werden. Wenn man zum Beispiel in Dolphin die Strg-Taste drückt, während man auf Dateien klickt, kann man mehrere Dateien auswählen. Damit dies funktioniert, liefert Qt praktischerweise die aktiven Modifikatoren mit jedem Eingabeereignis. Leider gingen bei der Tablet-Eingabe die Modifikatoren auf dem Weg verloren, so dass es nicht möglich war, mehrere Dateien mit einem Stift auszuwählen. Einen kleinen Fix später funktioniert es wie erwartet.

Das sind alle Wayland-Tablet-bezogenen Korrekturen für heute. Wenn Sie weitere Probleme in Qt/KDE-Anwendungen im Zusammenhang mit der Tablet-Eingabe auf Wayland finden, melden Sie diese bitte auf bugs.kde.org und ich werde sie mir ansehen.

Das ist aber noch nicht alles, was es an Verbesserungen für Wayland-Tablets gibt. Ganz im Sinne des KDE Goal We care about your input gibt es spannende Dinge, die auf der KWin/Plasma Seite passieren, an denen ich beteiligt gewesen bin.

In meiner Position als Software Platform Engineer bei KDE arbeite ich an gemeinsamen Bausteinen für KDE-Software, wie Qt und KDE Frameworks. Diese Arbeit ist dank Ihrer großzügigen Spenden möglich. Schauen Sie sich unsere Spendenaktion zum Jahresende an, wenn Sie mehr Arbeit wie diese sehen möchten.

💡 Wenn Sie Krita zum Zeichnen und Malen auf Ihrem Tablet verwenden, möchten Sie sich möglicherweise folgenden Artikel zu Gemüte führen:

Krita Brush Bundle 2025 & David Revoy

Ein Service von s3n🧩net