Neo als Zweitlayout führt zum Funktionsverlust von Mod4 #174

New Issue

Stephan · 2009-10-12T20:45:59+02:00

Stephan commented

2009-10-12 20:45:59 +02:00

Wird Neo als Zweitlayout verwendet, so sind die Ebenen 4 und 6 nicht erreichbar, stattdessen erscheinen die Ebenen 1 und 3.

Reproduzierbar durch:

setxkbmap de,de ,neo -option grp:sclk_toggle

Wird mit Scroll-Lock nun auf die Neo-Belegung gewechselt, so ist dort die Ebene 4 nicht mehr zu erreichen.

Wird Neo als Zweitlayout verwendet, so sind die Ebenen 4 und 6 nicht erreichbar, stattdessen erscheinen die Ebenen 1 und 3. **Reproduzierbar durch:** ``` setxkbmap de,de ,neo -option grp:sclk_toggle ``` Wird mit Scroll-Lock nun auf die Neo-Belegung gewechselt, so ist dort die Ebene 4 nicht mehr zu erreichen.

Stephan added the

Bug

Treiber/Linux/xkbmap

labels 2009-10-12 20:45:59 +02:00

peter.eberhard commented

2009-10-13 04:24:43 +02:00

Lösungsvorschlag:

• in <neo>/linux/X/symbols/level5 (bzw. /usr/share/X11/xkb/symbols/level5)

  replace key <MDSW> { 
    …
    symbols[Group1] = [ ISO_Level5_Shift ]

ersetzen durch:

    symbols[Group1] = [ ISO_Level5_Lock ]

• ebenfalls in symbols/level5:

  key <RALT> {
    …
    symbols[Group1] = [ ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Lock, ISO_Level5_Lock, ISO_Level5_Lock, ISO_Level5_Lock ]

ersetzen durch

  key <RALT> {
    …
    symbols[Group1] = [ ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift ],
    actions[Group1] = [ NoAction(), NoAction(), NoAction(), NoAction(), LockMods(modifiers = NumLock), LockMods(modifiers = NumLock), LockMods(modifiers = NumLock), LockMods(modifiers = NumLock) ]

( an zwei Stellen ).

Besonders die zweite Änderung hat vielleicht noch irgendwelche Nachteile, wenn es um die Kompatibilität geht. Das Problem ist, dass ein Neo-Benutzer, der ISO_Level5_Shift per Xmodmap ummappt, dann über Mod4+RAlt immer noch den Mod4-Lock erzeugt. Das sollte aber letztlich kein Problem sein, da Mod4+RAlt keine wichtige Tastenkombination ist. Und wenn man Mod4 woanders haben will, sollte man ohnehin die xkb-Options benutzen und das nicht per Xmodmap machen.

Kann das bitte noch jemand testen? Bei mir scheint es zu funktionieren.

Lösungsvorschlag: • in \<neo\>/linux/X/symbols/level5 (bzw. /usr/share/X11/xkb/symbols/level5) ``` replace key <MDSW> { … symbols[Group1] = [ ISO_Level5_Shift ] ``` ersetzen durch: ``` symbols[Group1] = [ ISO_Level5_Lock ] ``` • ebenfalls in symbols/level5: ``` key <RALT> { … symbols[Group1] = [ ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Lock, ISO_Level5_Lock, ISO_Level5_Lock, ISO_Level5_Lock ] ``` ersetzen durch ``` key <RALT> { … symbols[Group1] = [ ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift, ISO_Level5_Shift ], actions[Group1] = [ NoAction(), NoAction(), NoAction(), NoAction(), LockMods(modifiers = NumLock), LockMods(modifiers = NumLock), LockMods(modifiers = NumLock), LockMods(modifiers = NumLock) ] ``` ( an zwei Stellen ). Besonders die zweite Änderung hat vielleicht noch irgendwelche Nachteile, wenn es um die Kompatibilität geht. Das Problem ist, dass ein Neo-Benutzer, der ISO_Level5_Shift per Xmodmap ummappt, dann über Mod4+RAlt immer noch den Mod4-Lock erzeugt. Das sollte aber letztlich kein Problem sein, da Mod4+RAlt keine wichtige Tastenkombination ist. Und wenn man Mod4 woanders haben will, sollte man ohnehin die xkb-Options benutzen und das nicht per Xmodmap machen. Kann das bitte noch jemand testen? Bei mir scheint es zu funktionieren.

Stephan commented

2009-10-13 20:56:10 +02:00

Lösungsvorschlag:

[…]

Kann das bitte noch jemand testen? Bei mir scheint es zu funktionieren.

Bei mir verliert AltGr nach dem obigen Ersetzen seine Funktion als Mod4. Auch funktioniert AltGr dann nicht mehr als Ebene3-Modifikator, um beim deutschen Layout z.b. das „@“ Zeichen zu schreiben (AltGr + „q“).

Ich habe mit r2115 mal einen ganz einfachen Ansatz verfolgt, indem ich auch den vMod LevelFive mit dem realen Mod3 verbinde (früher war nur der Keysym ISO_Level5_Shift gebunden).
Den Ansatz habe ich mir einfach vom Neo-Mod4-Lock abgeschaut, da auch dort der vMod NumLock dem realen Mod2 zugewiesen wird.

Das behebt das Problem in diesem Ticket, es kann aber gut sein, dass weitere Probleme entstehen. Deshalb, wenn möglich, ausgiebig testen.

> Lösungsvorschlag: > > […] > > Kann das bitte noch jemand testen? Bei mir scheint es zu funktionieren. Bei mir verliert AltGr nach dem obigen Ersetzen seine Funktion als Mod4. Auch funktioniert AltGr dann nicht mehr als Ebene3-Modifikator, um beim deutschen Layout z.b. das „@“ Zeichen zu schreiben (AltGr + „q“). Ich habe mit r2115 mal einen ganz einfachen Ansatz verfolgt, indem ich auch den vMod LevelFive mit dem realen Mod3 verbinde (früher war nur der Keysym ISO_Level5_Shift gebunden). Den Ansatz habe ich mir einfach vom Neo-Mod4-Lock abgeschaut, da auch dort der vMod NumLock dem realen Mod2 zugewiesen wird. Das behebt das Problem in diesem Ticket, es kann aber gut sein, dass weitere Probleme entstehen. Deshalb, wenn möglich, ausgiebig testen.

peter.eberhard commented

2009-10-14 00:05:46 +02:00

Bei mir verliert AltGr nach dem obigen Ersetzen seine Funktion als Mod4. Auch funktioniert AltGr dann nicht mehr als Ebene3-Modifikator, um beim deutschen Layout z.b. das „@“ Zeichen zu schreiben (AltGr + „q“).

Hmm, ersteres Problem habe ich auch – ich dachte, das hätte ich getestet, aber ich hatte wohl nur den linken Mod4 ausprobiert. Ah... ich hatte die actions-Zeile weggelassen. Dann geht es wie gewünscht, aber der Mod4-Lock geht nur noch von rechts nach links (Mod4L+Mod4R geht nicht). Das Problem ergibt sich, weil die compat-Sachen die expliziten NoAction()s nicht überschreiben (hatte ich eigentlich angenommen), und außerdem automatisch auch in der ersten Gruppe eine NoAction() angelegt wird (unsinnigerweise). Ich halte das ja für einen Bug von xkbcomp, aber naja.

Ich habe mit r2115 mal einen ganz einfachen Ansatz verfolgt, indem ich auch den vMod LevelFive mit dem realen Mod3 verbinde (früher war nur der Keysym ISO_Level5_Shift gebunden).
Den Ansatz habe ich mir einfach vom Neo-Mod4-Lock abgeschaut, da auch dort der vMod NumLock dem realen Mod2 zugewiesen wird.

Das hatte ich ja auch schon probiert, funktioniert bei mir aber wider Erwarten nicht. Welche X.org-Version hast du? Bei mir ist es X.org 7.2 (xorg-server 1.2). Schon etwas älter. Wäre ja toll, wenn der Bug behoben wäre. Müsste ich mal wieder updaten nerv. Xkbconfig hatte ich schon mal manuell kompiliert (1.6), damit die neo-xkbmaps keine Probleme machen.

Das behebt das Problem in diesem Ticket,
Wie gesagt, wohl erst ab (frühestens) X.org 7.3.

Noch eine Anmerkung: vmods[group1] ist nicht ganz korrekt, die vmods werden einem Keycode, nicht einer Gruppe zugewiesen. Also nur vmods = LevelFive. Dem Parser ist es wohl aber egal. Und die entsprechende Action brauchst du gar nicht definieren, die wird schließlich nie ausgeführt, da man <MDSW> nicht drücken kann (Außerdem wird sie noch durch compat/level5 zugewiesen). Dasselbe gilt für <HYPR>.

Gruß, Peter

> Bei mir verliert AltGr nach dem obigen Ersetzen seine Funktion als Mod4. Auch funktioniert AltGr dann nicht mehr als Ebene3-Modifikator, um beim deutschen Layout z.b. das „@“ Zeichen zu schreiben (AltGr + „q“). Hmm, ersteres Problem habe ich auch – ich dachte, das hätte ich getestet, aber ich hatte wohl nur den linken Mod4 ausprobiert. Ah... ich hatte die actions-Zeile weggelassen. Dann geht es wie gewünscht, aber der Mod4-Lock geht nur noch von rechts nach links (Mod4L+Mod4R geht nicht). Das Problem ergibt sich, weil die compat-Sachen die expliziten NoAction()s nicht überschreiben (hatte ich eigentlich angenommen), und außerdem automatisch auch in der ersten Gruppe eine NoAction() angelegt wird (unsinnigerweise). Ich halte das ja für einen Bug von xkbcomp, aber naja. > Ich habe mit r2115 mal einen ganz einfachen Ansatz verfolgt, indem ich auch den vMod LevelFive mit dem realen Mod3 verbinde (früher war nur der Keysym ISO_Level5_Shift gebunden). > Den Ansatz habe ich mir einfach vom Neo-Mod4-Lock abgeschaut, da auch dort der vMod NumLock dem realen Mod2 zugewiesen wird. Das hatte ich ja auch schon probiert, funktioniert bei mir aber wider Erwarten nicht. Welche X.org-Version hast du? Bei mir ist es X.org 7.2 (xorg-server 1.2). Schon etwas älter. Wäre ja toll, wenn der Bug behoben wäre. Müsste ich mal wieder updaten *nerv*. Xkbconfig hatte ich schon mal manuell kompiliert (1.6), damit die neo-xkbmaps keine Probleme machen. > Das behebt das Problem in diesem Ticket, Wie gesagt, wohl erst ab (frühestens) X.org 7.3. Noch eine Anmerkung: vmods[group1] ist nicht ganz korrekt, die vmods werden einem Keycode, nicht einer Gruppe zugewiesen. Also nur vmods = LevelFive. Dem Parser ist es wohl aber egal. Und die entsprechende Action brauchst du gar nicht definieren, die wird schließlich nie ausgeführt, da man \<MDSW\> nicht drücken kann (Außerdem wird sie noch durch compat/level5 zugewiesen). Dasselbe gilt für \<HYPR\>. Gruß, Peter

Stephan commented

2009-10-14 13:03:25 +02:00

Hmm, ersteres Problem habe ich auch – ich dachte, das hätte ich getestet, aber ich hatte wohl nur den linken Mod4 ausprobiert. Ah... ich hatte die actions-Zeile weggelassen. Dann geht es wie gewünscht, aber der Mod4-Lock geht nur noch von rechts nach links (Mod4L+Mod4R geht nicht). Das Problem ergibt sich, weil die compat-Sachen die expliziten NoAction()s nicht überschreiben (hatte ich eigentlich angenommen), und außerdem automatisch auch in der ersten Gruppe eine NoAction() angelegt wird (unsinnigerweise). Ich halte das ja für einen Bug von xkbcomp, aber naja.

Es gibt unzählige Bugs in xkbcomp, das Problem ist, dass man die meistens nicht genau identifizieren kann, weil selbst das Protokoll (das bereits mehrere Jahre alt ist) bestimmte Dinge nicht genau spezifiziert.
Deshalb geht oftmals sogar „Probieren über Studieren“.

Das hatte ich ja auch schon probiert, funktioniert bei mir aber wider Erwarten nicht. Welche X.org-Version hast du?

Ich nutze X.org 7.4 (xorg-server 1.6), wobei das natürlich auch nicht die aktuelle Version ist.
Wenn ich dieses Wochenende Zeit habe, werde ich den xkb-Treiber auch auf xkeyboard-config 1.7 abstimmen, um das aktuell zu halten.

Noch eine Anmerkung: vmods[group1] ist nicht ganz korrekt, die vmods werden einem Keycode, nicht einer Gruppe zugewiesen. Also nur vmods = LevelFive. Dem Parser ist es wohl aber egal. Und die entsprechende Action brauchst du gar nicht definieren, die wird schließlich nie ausgeführt, da man <MDSW> nicht drücken kann (Außerdem wird sie noch durch compat/level5 zugewiesen). Dasselbe gilt für <HYPR>.

Stimmt, daran hatte ich nicht gedacht. vmods scheint unabhängig von der group zu sein.
Allerdings meine ich, dass ich mir damals durchaus etwas dabei gedacht habe, den vmod NumLock zusammen mit einer Action zu definieren.

Wenn ich bei <HYPR> die Action weglasse, ändert sich nichts. Wenn ich sie allerdings bei <MDSW> weglasse, dann funktioniert es nicht mehr und #174 tritt wieder auf. So genau erklären kann ich mir das allerdings nicht. Komischerweise wird nichtmal der reale Mod3 beim Tastendruck aktiviert (obwohl er eigentlich über modifier_map gebunden wurde).

Wenn r2115 keine kritischen Fehler verursacht, würde ich es vorerst so lassen und bitten, es ausgiebig zu testen.

> Hmm, ersteres Problem habe ich auch – ich dachte, das hätte ich getestet, aber ich hatte wohl nur den linken Mod4 ausprobiert. Ah... ich hatte die actions-Zeile weggelassen. Dann geht es wie gewünscht, aber der Mod4-Lock geht nur noch von rechts nach links (Mod4L+Mod4R geht nicht). Das Problem ergibt sich, weil die compat-Sachen die expliziten NoAction()s nicht überschreiben (hatte ich eigentlich angenommen), und außerdem automatisch auch in der ersten Gruppe eine NoAction() angelegt wird (unsinnigerweise). Ich halte das ja für einen Bug von xkbcomp, aber naja. Es gibt unzählige Bugs in xkbcomp, das Problem ist, dass man die meistens nicht genau identifizieren kann, weil selbst das Protokoll (das bereits mehrere Jahre alt ist) bestimmte Dinge nicht genau spezifiziert. Deshalb geht oftmals sogar „Probieren über Studieren“. > Das hatte ich ja auch schon probiert, funktioniert bei mir aber wider Erwarten nicht. Welche X.org-Version hast du? Ich nutze X.org 7.4 (xorg-server 1.6), wobei das natürlich auch nicht die aktuelle Version ist. Wenn ich dieses Wochenende Zeit habe, werde ich den xkb-Treiber auch auf xkeyboard-config 1.7 abstimmen, um das aktuell zu halten. > Noch eine Anmerkung: vmods[group1] ist nicht ganz korrekt, die vmods werden einem Keycode, nicht einer Gruppe zugewiesen. Also nur vmods = LevelFive. Dem Parser ist es wohl aber egal. Und die entsprechende Action brauchst du gar nicht definieren, die wird schließlich nie ausgeführt, da man \<MDSW\> nicht drücken kann (Außerdem wird sie noch durch compat/level5 zugewiesen). Dasselbe gilt für \<HYPR\>. Stimmt, daran hatte ich nicht gedacht. vmods scheint unabhängig von der group zu sein. Allerdings meine ich, dass ich mir damals durchaus etwas dabei gedacht habe, den vmod NumLock zusammen mit einer Action zu definieren. Wenn ich bei \<HYPR\> die Action weglasse, ändert sich nichts. Wenn ich sie allerdings bei \<MDSW\> weglasse, dann funktioniert es nicht mehr und #174 tritt wieder auf. So genau erklären kann ich mir das allerdings nicht. Komischerweise wird nichtmal der reale Mod3 beim Tastendruck aktiviert (obwohl er eigentlich über modifier_map gebunden wurde). Wenn r2115 keine kritischen Fehler verursacht, würde ich es vorerst so lassen und bitten, es ausgiebig zu testen.

Stephan closed this issue

2010-02-13 10:54:06 +01:00

Stephan commented

2010-02-13 10:54:06 +01:00

r2115 scheint das Problem für neuere Versionen von xorg und xorg-server zu beheben.

Sign in to join this conversation.

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: neo/neo-layout#174