[xkbmap] Tastenkombinationen mit 4./7. Ebene bei KDE-Programmen

[martin_r]

Bei KDE-Programmen funktionieren weiterhin die Tastenkombinationen Strg+Mod4+uivco und (Strg+)Shift+Mod4+uiaeolä4 nicht. Getestet mit kate. Fehlermeldung: Shortcut doppeldeutig → hat keine Wirkung.

[petere]

Bestätigt. KDE interpretiert offenbar z.B. Strg+Mod4+i gleichzeitig als Strg+i und bemerkt einen Konflikt.

[petere]

Den Konflikt von z.B. Shift+Mod4+u kann man beheben, wenn man das zweite Home in der Zeile key <AC01> { [ u, U, backslash, NoSymbol, Home, Home, includedin, NoSymbol ] }; durch ein NoSymbol ersetzt.

Ihr könnt das ausprobieren, ohne eure xkb/symbols/de zu editieren, indem ihr xmodmap -e "keysym u = u U u U backslash NoSymbol Home NoSymbol U222E" auf der Konsole ausführt. Analog mit den anderen Tasten.

Gibt es irgendeinen Grund für diese Verdopplung? Es scheint mir generell besser zu sein, diese doppelten Keysyms durch NoSymbol zu ersetzen. Aber vielleicht funktioniert dann etwas anderes nicht.

Bei den Strg+Mod4-Kombinationen hilft diese Änderung allerdings nicht. Eine schnelle Abhilfe, wenn es zu nervig wird, ist, die Strg+iuvco-Kombinationen anders zu definieren, aber das ist natürlich auch nicht schön.

Es scheint ein allgemeines Qt-Problem zu sein und damit zusammenzuhängen, dass ISO_Level5_Shift in Qt kein Äquivalent hat. Qt benutzt eigene Keysyms und nur die Modifier Shift, Strg, Alt, AltGr, Meta (=Windows-Tasten=X-Mod4) und Mode_switch (=ISO_Group_Shift), um plattformunabhängig zu sein. Beim Übersetzen X-Keysym zu Qt-Keysym geht dann was verloren, wenn man „exotische“ Keysyms nutzt, wie wir. Deshalb auch z.B. die Fehlermeldung, wenn man in KDE irgendeine Tastenkombination mit Mod4 definieren will.

So ganz hab ich das aber noch nicht durchdrungen. Ich wühle mich gerade durch die Quellen. Sehr wahrscheinlich können wir das von unserer Seite nicht beheben. Und die Qt- und KDE-Programmierer haben wahrscheinlich andere Prioritäten, als jedes Xkb-Feature 1:1 in Qt/KDE abzubilden :-(.

[anonymous]

OK. Ich habe die Ursache isoliert:

Qt kennt eine Methode namens „possibleKeys“. Sie ermittelt, welche verschiedenen Bedeutungen eine Tastenkombination haben kann. So kann Strg+Shift+i auch Strg+(Groß-I) bedeuten. Und man könnte per Xkbmap Strg+i auch auf, sagen wir mal, iota ummappen, dann könnte Strg+Shift+i auch Shift+iota bedeuten. Der Punkt ist, dass Qt es nicht wissen kann und deswegen erstmal alle diese Kombinationen untersucht. Das ist eigentlich auch vernünftig; im Prinzip ist es ein Designfehler von X, das Tastenkombinations-Modifier (Strg, Alt, Meta…) und Modifier, die Tastenbedeutungen verändern (Shift, Lock, ISO_Level3_Shift, …) nicht trennt. Andererseits gibt es genau dafür auch wieder gute Gründe (so müssten sonst für Shift+PfeilLinks etc. eigene Keysyms definiert werden, unschön).

Im unserem Falle Strg+Mod4+i ergeben sich Strg+Left und Strg+i als Möglichkeiten. Denn Qt kennt Mod4 (intern: ISO_Level5_Shift) nicht und ignoriert es. Dass diese beiden Tastenkombinationen belegt sind und Qt nicht entscheiden kann, welche gemeint ist, wird das entsprechend angezeigt: In QShortcutEvent wird ein Feld „ambiguous“ gesetzt. KDE registriert dies und gibt die Fehlermeldung aus.

Im anderen Fall, Shift+Mod4+u, können U, Shift+u, Home (die überflüssige Eintragung in der Pseudoebene) und Shift+Home gemeint sein. Von diesen sind Home und Shift+Home belegt ⇒ uneindeutig ⇒ Fehlermeldung. Wenigstens diesen Fall können wir beheben.

KDE achtet auch explizit darauf, dass Tastenkombinationen z.B. nur als Shift+I, nicht aber Strg+Shift+i eingetragen werden. Da es aber von Mod4 nichtmal was mitbekommt (Qt übergibt als Qt-keysym nur -1, da es die Taste nicht kennt), kann es das bei Mod4 nicht machen und meldet sich auch bei dem Versuch, eine Tastenkombination mit Mod4 einzutragen. Ob diese Fehlermeldung ein Bug ist, kann man sich streiten. Würde -1 einfach ignoriert, könnten wir mit Mod4 auch Tastenkombinationen definieren, sofern die Taste auf der 4. Ebene belegt ist.

Der eigentliche Bug steckt in Qt, das ISO_Level5_Shift a)überhaupt gar nicht kennt und b) nicht als Modifier erkennt.

Lösungsmöglichkeiten? • Der Bug mit den Shift-Kombis kann wie beschrieben behoben werden, indem in der Pseudoebene „NoSymbol“ eingetragen wird, statt die 4. Ebene zu wiederholen. Ich sehe nicht, dass das Probleme ergeben würde; die Pseudoebene ist schließlich genau für diese Funktionen frei gelassen. • Für die Strg-Kombis (und auch eventuelle Alt-, Win-, Strg-Alt- usw. -Kombis) gibt es keine einfache Lösung. Für uns am bequemsten wäre, Qt würde den Bug beheben. Das wäre aber schon eine eher große Umstellung: Für die internen Modifier ist nur noch ein einziges Bit frei, und da werden sie lange nachdenken, ehe sie das belegen. • Wir könnten statt ISO_Level5_Shift Meta oder Hyper o.ä. benutzen, das Qt kennt und als Modifier akzeptiert. So eine Lösung hätte aber unzählige Nachteile: Die Windows-Tasten wären im Gegenzug keine Modifier mehr, und wir wären auch sehr inkompatibel mit anderen xkb-Treibern. Inakzeptabel. • Wir könnten mit Redirect-Actions arbeiten. Irgendwer meinte aber, dass das leider nicht so richtig funktioniert, jedenfalls nicht bei älteren X-Servern. • In Neo 3 könnte man einen Mod als „Overlay“ deklarieren; das ist eine Fn-ähnliche Funktion, die die Tasten in einer gesamten Ebene auf andere ummappt. Das würde allerdings große Änderungen an der Struktur von Neo bedeuten

[anonymous]

Sorry für die lange Nachricht und die schlechte Formatierung, ich merke mir nie, dass ich hier nicht wie in einer PlainText-Mail schreiben kann.

[anonymous]

Das ist eigentlich auch vernünftig; im Prinzip ist es ein Designfehler von X, das Tastenkombinations-Modifier (Strg, Alt, Meta…) und Modifier, die Tastenbedeutungen verändern (Shift, Lock, ISO_Level3_Shift, …) nicht trennt.

XKB macht das eigentlich schon. Was zur Ebenenauswahl benutzt wird soll nicht nochmal als Modifier benutzt werden, es sei denn, die Belegung schreibt das ausdrücklich vor (mit dem preserve keyword), wie es zum Beispiel die Neo-xkbmap für das Shift für die Pseudoebene tut.

• Der Bug mit den Shift-Kombis kann wie beschrieben behoben werden, indem in der Pseudoebene „NoSymbol“ eingetragen wird, statt die 4. Ebene zu wiederholen.

Man will aber zum Beispiel zum Markieren Shift-Pfeiltaste verwenden können…

• Wir könnten mit Redirect-Actions arbeiten. Irgendwer meinte aber, dass das leider nicht so richtig funktioniert, jedenfalls nicht bei älteren X-Servern.

Es funktioniert zum Beispiel mit Xorg 6.8.2 (von anno 2005) oder Xsgi wie mit IRIX 6.2.22 ausgeliefert (von anno 2003). Probleme machen eher neuere Systeme, Ursache unbekannt. Es hängt zumindest nicht allein an der Version des Servers.

• In Neo 3 könnte man einen Mod als „Overlay“ deklarieren; das ist eine Fn-ähnliche Funktion, die die Tasten in einer gesamten Ebene auf andere ummappt. Das würde allerdings große Änderungen an der Struktur von Neo bedeuten

Ich habe die letzten paar Wochen mit einen rudimentären Treiber benutzt, der mit Overlays funktioniert. Man müsste wohl auch im Vollausbau ein paar Einschränkungen hinnehmen, und mir ist bein Experimentieren auch ein paarmal der Server abgestürzt. Aber bei XKB ist das normal, und die Vereinfachung gegenüber Redirect-Actions ist auch was wert.

Als weitere Option könnte man auch einen richtigen Treiber schreiben. Die Idee ist, physische Tasten mit Message-Actions zu belegen, diese im Treiber auszuwerten, und mit XTest dann auf Pseudotasten zu drücken, die die eigentliche Belegung tragen. Normale Programme sehen von den Message-Actions nichts sondern registrieren nur die Pseudotastendrücke. Der Treiber kann so Applikationen Beliebiges vorsetzen. Seit ein paar Tagen benutze ich einen (soweit noch sinnlosen) Treiber dieser Art, der physische Tasten 1:1 auf Pseudotasten abbildet. Dazu muss man allerdings ein Fehlerchen im X-Server beheben, aber machbar ist so ein Treiber im Prinzip.

[petere]

XKB macht das eigentlich schon. Was zur Ebenenauswahl benutzt wird soll nicht nochmal als Modifier benutzt werden, es sei denn, die Belegung schreibt das ausdrücklich vor (mit dem preserve keyword), wie es zum Beispiel die Neo-xkbmap für das Shift für die Pseudoebene tut.

Stimmt. Jetzt, wo du’s sagst, kommt mir das Verhalten von Qt da tatsächlich etwas seltsam vor. Kommt wahrscheinlich noch aus vor-xkb-Zeiten? Naja, bloß wegen Neo werden sie das aber auch nicht umstellen. Hmm, sowas dummes, KDE hat gerade angefangen, mir zu gefallen…

Wahrscheinlich muss man da wohl dieses Verhalten in possibleKeysXKB abstellen und die libQtGui.so.4 neu kompilieren. Bäh. Und dann kann man immer noch keine eigenen Tastenkombinationen mit Mod4 definieren.

Man will aber zum Beispiel zum Markieren Shift-Pfeiltaste verwenden können…

Oh, ich hatte es nur in KWrite/Kate getestet, und da funktioniert es… Aber in nicht-KDE-Anwendungen geht es mit NoSymbol nicht mehr, und z.B. in der Konqueror-Adresszeile auch nicht. Unsinnigerweise werden in Kate selbst so Dinge wie "Cursor nach links" über Tastenkombinationen erledigt.

Als weitere Option könnte man auch einen richtigen Treiber schreiben. […]

Interessante Idee. Ich nahm bisher immer an, einen richtigen Treiber müssten wir für den Kernel schreiben. Aber bei näherer Betrachtung geht genau das gar nicht, da X vom Kernel ja nur die scancodes übergeben bekommt.

Xtest kannte ich bisher gar nicht. Nur zur Nachfrage: Der Treiber läuft dann als X-Client, oder? D.h. jedes Tastaturereignis geht zweimal hin und her (Message vom Server an Treiber, dann Xtest-Befehl zurück an Server, dann KeyPress-Event an Client). Sieht nicht besonders performant aus, wenn man z.B. den Server über ein Netzwerk betreibt? Keine Ahnung.

[anonymous]

Naja, bloß wegen Neo werden sie das aber auch nicht umstellen.

Du hast wohl recht, zumal die Formulierung in „The X Keyboard Extension: Protocol Specification“ windiger ist als ich sie in Erinnerung hatte. Abschnitt 7.2.1 klingt noch gut:

… Any modifiers specified in modifiers are normally consumed (see section 7.3), which means that they are not considered during any of the later stages of event processing. …

In Abschnitt 7.3 wird es schwammiger:

Any modifiers that were not used to look up the keysym, or which were explicitly preserved, might indicate further transformations to be performed on the keysym or the character string that is derived from it. …

Ich bin mir nicht sicher, ob das konkret genug ist, um das Verhalten von Qt als fehlerhaft nachzuweisen.

Oh, ich hatte es nur in KWrite/Kate getestet, und da funktioniert es… Aber in nicht-KDE-Anwendungen geht es mit NoSymbol nicht mehr, und z.B. in der Konqueror-Adresszeile auch nicht.

Ich habe hier kein Qt/KDE und kann es nicht probieren: Wie weit kommt man mit einen neuen XKB type, der für Mod4 und Shift-Mod4 denselben Level auswählt, also einem type mit sechs statt acht Ebenen?

Xtest kannte ich bisher gar nicht.

Eine weitere interessante X Extension in diesem Zusammenhang ist XRecord. Aber eigentlich gehört das nicht hierher…

Der Treiber läuft dann als X-Client, oder? D.h. jedes Tastaturereignis geht zweimal hin und her (Message vom Server an Treiber, dann Xtest-Befehl zurück an Server, dann KeyPress-Event an Client).

Genau.

Sieht nicht besonders performant aus, wenn man z.B. den Server über ein Netzwerk betreibt? Keine Ahnung.

Man lässt den Treiber idealerweise auf der demselben Rechner wie den Server laufen (also typischerweise auf dem Rechner an dem man sitzt), dann kann die zusätzliche Kommunikation lokal ablaufen.