[xkbmap] Mod4 wird nicht erkannt in Mathematica und Ratpoison #74

Closed
opened 15 years ago by erik · 8 comments
erik commented 15 years ago
Collaborator

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).

Wenn man unter Linux die **xkbmap** verwendet und in [Wolfram Mathematica](http://www.wolfram.com/products/mathematica/index.html) 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 added the
Bug
Treiber/Linux/xkbmap
labels 15 years ago
erik changed title from buy lioresal to [xkbmap] Mod4 wird nicht erkannt in Mathematica und Ratpoison 14 years ago
Poster
Collaborator

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.

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.

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).

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 self-assigned this 14 years ago
Poster
Collaborator

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)?

> 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](src/branch/master/linux/X/de) 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)?
Poster
Collaborator

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. :-(

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. :-(

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

Die Methode mit Num_Lock und actions funktioniert auch für Mathematica (ausprobiert mit Version 6.0).
erik closed this issue 14 years ago
Poster
Collaborator

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.

> 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.

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.

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.
der Link zum xorg-Bug: https://bugs.freedesktop.org/show_bug.cgi?id=21910
Sign in to join this conversation.
Loading…
There is no content yet.