Re: [Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

2010-06-23 Diskussionsfäden Dennis Heidsiek

Hallo allerseits,


Peter Eberhard ſchrieb am 21.06.2010 18:20 Uhr:

Bin gespannt, ob das unverständliche Gelaber jetzt wirklich einer liest:-).


Gelesen schon, aber nicht geistig durchdrungen ;)


Viele Grüße,
Dennis-ſ




Re: [Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

2010-06-21 Diskussionsfäden Peter Eberhard
OK, ich bin dem Problem auf den Grund gegangen. Letztlich hatte ich mit meiner 
ersten Vermutung, es liege am Key-repeat, doch recht. Die Mechanismen sind 
dann aber doch etwas anders.

möglicher Workaround:
ersetze die Zeile:

keycode 51 =  ISO_Group_Shift ISO_Group_Shift ISO_First_Group  NoSymbol 

durch

keycode 51 =  ISO_Group_Shift ISO_Group_Shift ISO_First_Group  NoSymbol  
NoSymbol  NoSymbol  ISO_First_Group

Das ist aber kein echter Fix, denn nun tritt ein anderes Problem auf: Sobald 
der Key-repeat einsetzt, kehrt man von der 6. wieder in die 3. Ebene zurück. 
Wenigstens ist man aber wieder in Ebene 1, wenn die Tasten losgelassen werden. 
Mit Xmodmap-Mitteln gibt es keinen echten Workaround, weil ein Bug im X-Server 
vorliegt.

Die wirkliche Abhilfe ist, die Skripte installiere_neo und asdf zu benutzen. 
Die deaktivieren den key-Repeat von allen Modifiern. Oder man macht es selbst 
per:
xset -r 51

Statt setxkbmap lv && xmodmap neo_de.xmodmap
also immer: setxkbmap lv && xmodmap neo_de.xmodmap && xset -r 51


Erklärung mit vielen technischen Details für Interessierte:
Nur ganz kurz zur Theorie: X unterscheidet Gruppen und Levels. Gruppen (max. 
4) sind im Prinzip unabhängige Layouts mit bis zu 256 Levels. Levels 
entsprechen im Prinzip den Neo-Ebenen. Jede Taste kann für jede Gruppe und 
jedes Level eine andere Belegung haben. Mit einer xkbmap kann man das auch 
tatsächlich realisieren.
Früher, vor der x keyboard extension, gab es nur genau 2 Gruppen mit genau 2 
Levels. Die Xmodmap ist damit kompatibel, und so stehen die ersten zwei 
Spalten für die 1. Gruppe, die 3. und 4. Spalte für die zweite Gruppe. Danach 
kommen die restlichen Levels der ersten Gruppe dran, dann die dritte und 
vierte Gruppe.
Die 8 Spalten der Neo-Xmodmap entsprechen also:
G1L1, G1L2, G2L1, G2L2, G1L3, G1L4, G3L1, G3L2.

Nur, damit das Palaver von Gruppen klarer wird.

Mod3r, also die Taste Nr. 51, hat nun (s.o.) in der ersten Gruppe ein 
Group_Shift stehen, in der zweiten ein First_Group. Das sind aber zwei ganz 
verschiedene Aktionen:
‣ Group_Shift erhöht die aktuelle Gruppe um 1, ist aber _temporär_ und wird, 
wenn die Taste losgelassen wird, wieder aufgehoben.
‣ First_Group setzt die Grundeinstellung auf die 1. Gruppe. Keine Aktion beim 
Loslassen.
Diese beiden Dinge – temporäre und grundsätzliche Gruppe – werden aber in zwei 
verschiedenen Variablen gespeichert! (base_group und locked_group)

Seit dem X.org-Server 1.6 werden die key-repeats nur noch per Software direkt 
im X-Server simuliert. Die xev-Ausgabe ist insofern irreführend, als dass die 
KeyRelease-Ereignisse gar nicht mehr stattfinden; sie werden nur aus 
Kompatibilitätsgründen noch vom Server an die Anwendung (z.B. xev) gesendet, 
haben aber keine direkten Seiteneffekte mehr (z.B. Modifier verändern). 
Der „virtuelle“ KeyRelease wird dabei unmittelbar beim neuen Repeat-Keypress 
mit verarbeitet. Der Server merkt sich, dass die Taste gedrückt ist, und macht 
die entsprechenden Release-Aktionen, wenn die gleiche Taste wiederholt (per 
Keyrepeat) oder losgelassen wird.

Der Ablauf müsste eigentlich so sein:
KeyPress: base_group += 1
KeyPress: base_group -= 1, base_group += 1
KeyPress: base_group -= 1, base_group += 1
usw. usf.
Dann hätten wir auch kein Problem.

Was tatsächlich passiert, ist dies (aufs allerwesentlichste reduziert):
KeyPress: groupChange = 1, base_group += groupChange
KeyPress: groupChange = -1, groupChange = 1, base_group += groupChange
...
D.h. das Rückgängigmachen des vorhergehenden KeyPress wird sofort durch den 
neuen KeyPress überschrieben. Korrekt wäre folgende 2. Zeile:
KeyPress: groupChange -= 1, groupChange += 1, base_group += groupChange

Hier liegt also offensichtlich ein Bug im X-Server (xkb/xkbActions.c) vor. Ich 
denke mal fast, ich bin der erste, der ihn entdeckt hat. Jedenfalls ist er 
auch noch in der aktuellen Entwicklerversion.

Die Gruppen werden nur nicht zyklisch immer weiter erhöht, weil wir in der 
zweiten (und damit auch vierten) Gruppe ein ISO_First_Group stehen haben. Das 
erhöht die Gruppe nicht weiter. Am Ende bleibt deshalb die base_group = +1 
stehen.

Und da kommt man auch nicht raus, wenn man, wie von mir 
in der letzten Mail vorgeschlagen, ISO_First_Group auf Rollen legt. Denn 
dadurch kann nur locked_group beeinflusst werden. Ebenso alle anderen keysyms 
(ISO_Next_Group usw.). Man kommt einfach nicht mehr raus. (Nun ja, ganz 
richtig ist das auch nicht: Man kann durch verschiedene Reihenfolgen von Mod3 
drücken, halten und loslassen die base_group weiter erhöhen, bis man bei 5 
ankommt. Die 5. Gruppe ist aber die 1. Gruppe, da es nur vier gibt).

Obiger „Fix“ bewirkt, dass das ISO_First_Group schon in der dritten Gruppe 
steht – damit wird die falsche Zeile gar nicht erst ausgeführt, dafür 
stattdessen:
KeyPress: groupChange -= 1, locked_groups = 1, base_group += groupChange
Das ist aber auch nicht richtig, denn jetzt ist die base_group um 1 zu klein.

Wir müssen letztlich den key-repeat unbedingt vermeiden u

Re: [Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

2010-06-20 Diskussionsfäden Peter Eberhard
> > ‣ Als schneller Workaround bietet sich somit ein ISO_First_Group an,
> > dass man auf die 3. und 6. Ebene von Rollen oder so legt. So müsste man
> > wenigstens wieder an die 1. Ebene kommen.
> 
> Hättest Du einen Patch? Leider habe ich keine Ahnung von den ganzen
> Dingen.

Öhm… ich hab dafür keine Ahnung, wie man Patches unter Linux verbreitet. Da 
gibts doch irgendeine geschickte Syntax für entsprechende Tools, oder?
Wie auch immer, wenn du

keysym Scroll_Lock = ISO_First_Group

in der Xmodmap anfügst, müsste es eigentlich gehen. Durch Rollen kannst du 
dann zurück in die erste Gruppe (erste Ebene).

Zum Testen kannst du auch noch

keysym Pause = ISO_Next_Group

hinzufügen, damit kommst du durch einmal „Pause“-Taste in einen Mod3-Lock; ein 
zweites Mal, und du hast einen Mod6-Lock. Komischerweise komme ich jetzt grade 
auch mit einem einfachen Mod3 aus dem Mod3Lock raus.

Noch zu xev:
Die Angabe „state“ gibt die aktiven Mods an. Wenn bei einem Keypress-Event der 
state nicht 0x ist, du aber keine Mods gedrückt hältst, ist ein Lock 
aktiv:
0x0001 Shift
0x0002 Caps
0x0004 Strg
0x0008 Alt
0x0010 NumLock (bei Qwert) bzw. Mod4Lock (Neo-xkbmap)
0x0020 Mod3 (hmm, scheint aber nicht aktiviert zu werden, seltsam…)
0x0040 Win/Super
0x0080 Neo-Mod4
0x0100-0x1000 Maustasten
0x2000 2. Gruppe (4. Neo-Ebene)
0x4000 3. Gruppe (6. Neo-Ebene)
0x6000 4. Gruppe (nicht belegt)

So kannst du die Ausgaben von xev besser nachvollziehen.

> > Der Rest war auch Blödsinn:
> > ‣ Ein Key-repeat-Problem gibt es bei unserem Treiber auch nicht, das war
> > nur bei meinem eigenen abgewandelten der Fall. Und das kann man leicht
> > durch "xset -r " beheben.
> 
> Wenn Du damit meinst, das bei gedrückter rechter Mod3-Taste, `xev` viele
> Events meldet und bei der linken nicht, kann ich das auf meinem System
> reproduzieren. (Ergänzung: Das war vor der Neuanmeldung, als die 3.
> Ebene festgestellt war.)

Ah! Ich hatte keinen Key-repeat, weil ich unter Ubuntu das eingebaute Neo-
Layout als Grundlayout eingestellt habe (das aber durch eine eigene xmodmap 
überschrieben wird). Und das deaktiviert den Keyrepeat von Mod3r.

Jetzt unter openSuse hab ich ihn aber auch wieder. Das Problem des Mod3-Locks 
tritt trotzdem nicht auf (im Unterschied zu Ubuntu). Xev reagiert hier auch 
anders — es gibt bei Mode_switch nicht immer gleich noch ein KeymapNotify-
Event hinterher. Das mag ein Bugfix im X-Server 1.8 sein, den openSuse 11.3-
rc1 benutzt.

Das muss ich mir nochmal genauer ansehen. Scheint doch alles ziemlich 
distributionsabhängig zu sein. Vielleicht sollte ich mir auch mal Debian 
draufmachen (wollte ich ohnehin mal ausprobieren).

Gruß,
Peter



[Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

2010-06-20 Diskussionsfäden Paul Menzel
Am Sonntag, den 20.06.2010, 20:47 +0200 schrieb Peter Eberhard:
> Am Freitag, den 18.06.2010, 14:22 +0200 schrieb Peter Eberhard:
> > > das Problem tritt immer noch auf und ich kann es jetzt reproduzieren. Es
> > > passiert immer, wenn die 6. Ebene (Math-Modus) benutze. Nach ein paar
> > > Zeichen bekomme ich einen Mod*3*-Lock.
> > 
> > kurze Antwort für Pragmatiker:
> > • schnelle Hilfe: Mod3r nochmal gedrückt halten. Mit etwas Glück bist du
> > dann wieder in der 1. Ebene. Wenn nicht, nochmal probieren.
> > • generelle Vermeidung des Problems: xkbmap benutzen.

> sorry, das war ja mal völliger Schwachsinn von mir.

Kein Problem. Danke, dass Du Dich darum kümmerst.

> ‣ Bei mir trat das Problem vorhin auch auf, ich kann es aber nicht mehr
> reproduzieren. Insbesondere weiß ich nicht, was xev dabei so anzeigt.
> Bei mir war allerdings die SECHSTE Ebene gelockt. Das ist sicherlich der
> gleiche Fehler, denn intern sind sowohl die 3. und 6. Ebene als 2. und
> 3. Gruppe realisiert (also im Prinzip als unabhängige Zweit- und
> Drittlayouts). Wenn die Gruppe gelockt ist, kommt man nicht mehr zurück.
> 
> ‣ Als schneller Workaround bietet sich somit ein ISO_First_Group an,
> dass man auf die 3. und 6. Ebene von Rollen oder so legt. So müsste man
> wenigstens wieder an die 1. Ebene kommen.

Hättest Du einen Patch? Leider habe ich keine Ahnung von den ganzen
Dingen.

> ‣ Egal, wie oft ich die sechste Ebene tippe, und mit welchen Modifiern,
> ich krieg es nicht mehr reproduziert. Keine Ahnung.
> 
> ‣ Wenn du den in
> http://wiki.neo-layout.org/ticket/189
> angegebenen Fix anwendest, tritt das Problem immer noch auf? Nur ein
> Schuss ins Blaue, ich weiß momentan überhaupt nicht mehr, was da
> eigentlich los ist.
> Wenn es immer noch auftritt, sollten wir ein Ticket aufmachen.

In einem laufenden System, wo vorher die unveränderte xmodmap geladen
war, führte ich Deine Änderungen durch und lud diese neu.

$ setxkbmap lv && xmodmap ~/neo_de.xmodmap

Danach konnte ich das Problem schnell reproduzieren. Mod3r und Mod4r
drücken und mit der linken Hand schnell ein paar Zeichen eingeben und
die 3. Ebene ist festgestellt.

Als ich mich dann abmeldete und neu anmeldete wollte ich Dir die
xev-Ausgabe schicken. Jetzt kann ich es aber nicht mehr reproduzieren.
Komisch.

> Der Rest war auch Blödsinn:
> ‣ Ein Key-repeat-Problem gibt es bei unserem Treiber auch nicht, das war
> nur bei meinem eigenen abgewandelten der Fall. Und das kann man leicht
> durch "xset -r " beheben.

Wenn Du damit meinst, das bei gedrückter rechter Mod3-Taste, `xev` viele
Events meldet und bei der linken nicht, kann ich das auf meinem System
reproduzieren. (Ergänzung: Das war vor der Neuanmeldung, als die 3.
Ebene festgestellt war.)

> ‣ Unter Suse 9.0 tritt der Keyrepeat auch auf (konträr zu meiner
> Aussage), aber ohne die beschriebene Nebenwirkung.
> 
> Also, sorry, da hab ich mal wieder keine Sorgfalt walten lassen.

Ich kann es nur wiederholen. Danke, dass sich einer darum kümmert.

Was mich nur wundert ist, dass Pascal ja dieses Problem auch bestätigte.
Verwenden alle Sechste-Ebenen-Benutzer die xkbmap?

Ich werde mich melden, wenn ich das Problem wieder haben sollte.


Liebe Grüße,

Paul


signature.asc
Description: This is a digitally signed message part


Re: [Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

2010-06-18 Diskussionsfäden Peter Eberhard
> das Problem tritt immer noch auf und ich kann es jetzt reproduzieren. Es
> passiert immer, wenn die 6. Ebene (Math-Modus) benutze. Nach ein paar
> Zeichen bekomme ich einen Mod*3*-Lock.

kurze Antwort für Pragmatiker:
• schnelle Hilfe: Mod3r nochmal gedrückt halten. Mit etwas Glück bist du
dann wieder in der 1. Ebene. Wenn nicht, nochmal probieren.
• generelle Vermeidung des Problems: xkbmap benutzen.

langatmige Analyse für Adepten:

Ich hab kein Debian, aber ein ähnliches Problem unter anderen
Distributionen mit dem aktuellen X.org-Server.
Scheint so, dass da ein Bug vorliegt: Normalerweise sollten Tasten, die
durch Xmodmap mit einem Modifier belegt werden, automatisch die
Tasten-Wiederholungsfunktion abschalten, so dass nur beim erstmaligen
Tastendruck ein Ereignis erzeugt wird, aber nicht mehr, wenn die Taste
länger gedrückt gehalten wird. Bei Mod3r scheint das aber nicht mehr zu
funktionieren.
Ob das bei dir der Fehler ist, kannst du unter xev nachvollziehen: Mod3r
erzeugt da, wenn es gedrückt gehalten wird, fortwährend Ereignisse. Wenn
sie losgelassen wird, ist es Zufall, ob Mod3 gerade aktiv ist (und
bleibt) oder nicht.
Das sollte dann auch bei der dritten Ebene auftreten, aber weil du da
wohl immer die Taste nur schnell anschlägst, hast du es noch nicht
bemerkt. Bei der 6. Ebene drückst du Mod3 länger, weil du auch noch Mod4
betätigen musst; schon fängt die Tastenwiederholung an, und du hast
deine ½-Chance, dass Mod3 aktiv bleibt.

Unmittelbar kannst du das Problem dadurch umgehen, indem du den Mod
nochmal lange gedrückt hältst und das solange probierst, bis Mod3 wieder
inaktiv ist. Nervig, aber so musst du wenigstens nicht ausloggen.

Ansonsten hilft nur die xkbmap: Dort sollte das eigentlich nicht
auftreten.

Wenn ich mal mehr Zeit hab, guck ich vielleicht mal, ob das tatsächlich
ein Xkb-Bug ist oder ob ich da auf dem falschen Dampfer bin.

Vielleicht tritt der Fehler auch nur bei Mod3 auf, das in der Xmodmap
als ISO_Group_Shift kodiert ist, also gar kein richtiger Modifier ist,
sondern die Gruppe ändert. Sollte sich aber _eigentlich_ gleich
verhalten. Die Grundlage ist die Zeile

interpret.repeat = false

in /usr/share/X11/xkb/compat/basic. Dies sollte eigentlich bewirken,
dass die Tasten, die nachfolgend behandelt werden (nämlich alle Modifier
inklusive Mode_switch, das mit ISO_Group_Shift identisch ist), keine
Tastenwiederholung benutzen. Auch, wenn sie durch die Xmodmap belegt
werden.
Funktioniert aber nich mehr :-(.

Ich hab auch noch ein altes Suse 9.0 (von 2003!) hier rumliegen: Da
gibts keine Beanstandungen. Das ist also definitiv ein Bug, der erst in
letzter Zeit dazugekommen ist.

Gruß,
Peter




Re: [Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

2010-06-18 Diskussionsfäden Paul Menzel
Liebe Leute,


Am Samstag, den 06.02.2010, 09:51 +0100 schrieb Paul Menzel:

> gestern passierte es mir, dass ich durch drücken irgendeiner
> Tastenkombination, an die ich mich nicht mehr erinnern kann, einen
> Ebene-3-Lock hatte.

das Problem tritt immer noch auf und ich kann es jetzt reproduzieren. Es
passiert immer, wenn die 6. Ebene (Math-Modus) benutze. Nach ein paar
Zeichen bekomme ich einen Mod*3*-Lock.

> Leider konnte den Lock nicht abschalten und mir
> blieb nur mich abzumelden und wieder anzumelden.
> 
> Die Suche im Netz zeigte, dass es einen Ebene-3-Lock eigentlich gar
> nicht geben soll [1]. Wie in [2] berichtet, gibt es beim Laden der
> Dateien eine Fehlermeldung. Vielleicht hat das damit zu tun.
> 
> $ setxkbmap lv && xmodmap neo_de.xmodmap 
> X Error of failed request:  BadValue (integer parameter out of range 
> for operation)
>   Major opcode of failed request:  118 (X_SetModifierMapping)
>   Value in failed request:  0x17
>   Serial number of failed request:  86
>   Current serial number in output stream:  86
> 
> Kann mir jemand bitte Tipps geben, wie ich das erstens nächstes Mal
> beheben kann und zweitens was ich tun kann – außer mir die auslösende
> Tastenkombination zu merken –, um die Fehlerursache finden zu können?

Ich benutze Debian Sid/unstable mit `x11-xserver-utils` 7.5+1+b1.
(Gleich Version wie im Februar.)

Damit ist der Mathe-Modus/die 6. Ebene für mich nicht benutzbar. Könntet
Ihr mir weiterhelfen oder es bei Euch einmal testen? (Ich glaube, bei
Zeichenfolgen, die ∈ öfters enthielten, trat das Problem öfters auf.


Liebe Grüße,

Paul


> [1] http://wiki.neo-layout.org/wiki/Locks
> [2] http://wiki.neo-layout.org/ticket/189


signature.asc
Description: This is a digitally signed message part