[xkbmap] Mod4 wird nicht erkannt in Mathematica und Ratpoison

[Erik Streb del Toro]

Wenn man unter Linux die xkbmap verwendet und in ​Wolfram Mathematica einen der beiden Mod4 drückt, erscheint ein Zeichen, das aussieht wie ein Leerzeichen. Wenn ich es aber markiere und in gucharmap eingebe, sehe ich, dass es eigentlich folgendes ist:

\:ffff

Was soll das sein?

Die 4. Ebene funktioniert ansonsten tadellos, nur, dass überall diese Leerzeichen hinterlassen werden, und man diese alle suchen und wieder rauslöschen muss, bevor man etwas berechnen lassen kann.

Wenn ich die Xmodmap benutze, funktioniert Mod4 ohne Probleme.

PS: Interessieren würde mich auch, ob dieser Fehler auch unter Windows auftritt (mit AHK oder kbdneo2).

[Erik Streb del Toro]

Ein vielleicht ähnlicher Fehler tritt mit Ratpoison auf:

xkbmap-Treiber: Wenn ich statt des echten Tab versuche den Mod4-Tab zu verwenden (Mod4+ö), um den Frame zu wechseln, erscheint nur die Fehlermeldung:

readkey: unbound key 'ISO_Level5_shift'

Wenn ich irgendwelche Mod3-Zeichen eingeben will, ist das kein Problem. Es scheint also, als würde Mod4 nicht als Modifikator-Taste erkannt werden.

Mit der Xmodmap-Version funktioniert es einwandfrei.

[Andreas Wettstein]

Ich kann das Problem für ratpoison nachvollziehen und umgehen, indem ich Mod4 so umbelege:

type= "ONE_LEVEL", vmods= LevelFive, symbols[Group1]= [ Num_Lock ], actions[Group1]= [ SetMods(modifiers=LevelFive) ]

LevelFive wird dann direkt über actions statt über xkb_compatibility gesetzt. Die keysym kann man daher freier wählen. Num_Lock bietet sich an, weil die meisten Programme es als Umschalttaste erkennen sollten, aber nur vermutlich nur wenige Programme NumLock selbst behandeln (z.B. bei Shift wäre das vermutlich anders).

[Erik Streb del Toro]

Replying to Andreas Wettstein:

Ich kann das Problem für ratpoison nachvollziehen und umgehen, indem ich Mod4 so umbelege:

type= "ONE_LEVEL", vmods= LevelFive, symbols[Group1]= [ Num_Lock ], actions[Group1]= [ SetMods(modifiers=LevelFive) ]

LevelFive wird dann direkt über actions statt über xkb_compatibility gesetzt. Die keysym kann man daher freier wählen. Num_Lock bietet sich an, weil die meisten Programme es als Umschalttaste erkennen sollten, aber nur vermutlich nur wenige Programme NumLock selbst behandeln (z.B. bei Shift wäre das vermutlich anders).

Vielen Dank für Deine kompetente Hilfe. Bist Du aber sicher, dass dadurch keine anderen Probleme entstehen? Ansonsten könnte man dies mal ausprobieren. Oder ist das mit der aktuellen xkbmap eh schon gelöst? Oder wenn in den nächsten Tagen von Stephan (siehe Ticket #33) die Mods intern getauscht werden (Mod3 ↔ Mod4 ⇔ Level 3 ↔ Level 5)?

[Erik Streb del Toro]

Problem hat sich mit der neuen Version der xkbmap (r1803) bei Mathematica nun von Mod4 auf Mod3 verlagert. Das ist sehr ungünstig, da man die Rechenzeichen und Klammern (+-*/) auf Ebene 3 hat. Somit ist Mathematica mit Neo eigentlich gar nicht mehr bedienbar. :-(

[wettstein509@…]

Die Methode mit Num_Lock und actions funktioniert auch für Mathematica (ausprobiert mit Version 6.0).

[Erik Streb del Toro]

Replying to wettstein509@solnet.ch:

Die Methode mit Num_Lock und actions funktioniert auch für Mathematica (ausprobiert mit Version 6.0).

Ja, und mit Eurer (Stephans und Deiner) kombinierten Arbeit in r1824 auch endgültig für alle einfach zu testen.

Dieser Fehler wird hiermit geschlossen.

[wettstein509@…]

Dieses Ticket wird mit Revision 1879 wieder aktuell. Daher eine Aktualisierung:

Das Problem für ratpoison geht auf einen Fehler im Makro IsModifierKey im Standard-Header include/X11/Xutil.h zurück. Ich habe den Fehler vor ein paar Tagen gemeldet. Er ist leicht zu beheben, ist aber noch offen. Und bis von der Korrektur auch kommerzielle Programme profitieren kann unter Umständen Jahre dauern.

Trotzdem bin ich der Meinung, dass dieses Ticket nach wie vor als erledigt angesehen werden sollte. Neo macht nichts falsch.

[stephan]

der Link zum xorg-Bug: ​https://bugs.freedesktop.org/show_bug.cgi?id=21910