Neue xkbmap-Version setzt xkbmap außer Gefecht

[martin_r]

Bei setxkbmap <*> erscheint nur folgende Fehlermeldung: Couldn't find rules file (xorg)

[wettstein509@…]

Das liegt wahrscheinlich daran, dass bei der Installation die Zugriffsrechte verändert wurden.

Bitte prüfe, ob im xkb-Verzeichnis (wohin du die neu Version installiert hast) die Datei rules/xorg existiert und du (auch als normaler User) Leserechte hast. Wenn rules/xorg ein symbolischer Link ist prüfe dasselbe für die verlinkte Datei. Passe die Leserechte gegebenfalls an.

[martin_r]

Replying to wettstein509@solnet.ch:

Das liegt wahrscheinlich daran, dass bei der Installation die Zugriffsrechte verändert wurden. Bitte prüfe, ob im xkb-Verzeichnis (wohin du die neu Version installiert hast) die Datei rules/xorg existiert und du (auch als normaler User) Leserechte hast. Wenn rules/xorg ein symbolischer Link ist prüfe dasselbe für die verlinkte Datei. Passe die Leserechte gegebenfalls an.

Das habe ich getippt:

cd /usr/share/X11/xkb
sudo chmod o=r symbols/de types/level5 rules/base symbols/shift

Fehlermeldung jetzt:

Error loading new keyboard description

[anonymous]

Replying to martin_r:

Das habe ich getippt: {{{ cd /usr/share/X11/xkb sudo chmod o=r symbols/de types/level5 rules/base symbols/shift }}} Fehlermeldung jetzt: Error loading new keyboard description

Interessant. Diesen Fehler hatte ich auch schon zweimal und habe ihn nur durch Reinstallation des Pakets xkeyboard-config beheben können. Anschließend habe ich die Dateien wieder einzeln hinkopiert und es funktioniert seitdem. Dass es an den Rechten liegen könnte, habe ich noch nicht bedacht. Bei mir sehen die Rechte und Besitzer(!) dieser vier Dateien momentan so aus:

-rw-r--r-- 1 root root 32830 19. Mai 07:35 /usr/share/X11/xkb/rules/base
-rw-r--r-- 1 root root 34652 19. Mai 08:09 /usr/share/X11/xkb/symbols/de
-rw-r--r-- 1 root root  1067 19. Mai 07:35 /usr/share/X11/xkb/symbols/shift
-rw-r--r-- 1 root root  7233 19. Mai 07:35 /usr/share/X11/xkb/types/level5

Damit funktioniert es einwandfrei. Um diese Rechte zu erreichen solltest Du eingeben:

cd /usr/share/X11/xkb
sudo chown root: symbols/de types/level5 rules/base symbols/shift
sudo chmod u=rw,g=r,o=r symbols/de types/level5 rules/base symbols/shift

Funktioniert es jetzt wieder?

Ich konnte damals, als der Fehler auftrat, trotzdem im Nachhinein mit

setxkbmap de neo

auf Neo wechseln.

[erik]

r1860 ist ein Versuch das zu beheben. Klappt’s?

[martin_r]

Replying to erik:

r1860 ist ein Versuch das zu beheben. Klappt’s?

Rechte stimmen jetzt. Aber die xkbmap kann ich immer noch nicht laden :(

[erik]

Replying to martin_r:

Replying to erik:

r1860 ist ein Versuch das zu beheben. Klappt’s?

Rechte stimmen jetzt. Aber die xkbmap kann ich immer noch nicht laden :(

Bitte installiere das Paket xkeyboard-config (heißt bei Fedora zumindest so) nochmal neu. Also entfernen würde ich es nicht, da sonst nix mehr funktioniert, sondern einfach drüber installieren. Weiß nicht, wie das bei Debian/Ubuntu geht. Frag im IRC.

Danach nochmal die xkb.tgz an die richtige Stelle entpacken. Zumindest hat das bei mir geholfen. Leider weiß ich aber auch noch nicht, was sich dadurch (durch die Reinstallation von xkeyboard-config) geändert/korrigiert hat.

[martin_r]

Replying to erik:

Replying to martin_r:

Replying to erik:

r1860 ist ein Versuch das zu beheben. Klappt’s?

Rechte stimmen jetzt. Aber die xkbmap kann ich immer noch nicht laden :(

Bitte installiere das Paket xkeyboard-config (heißt bei Fedora zumindest so) nochmal neu. Also entfernen würde ich es nicht, da sonst nix mehr funktioniert, sondern einfach drüber installieren. Weiß nicht, wie das bei Debian/Ubuntu geht. Frag im IRC. Danach nochmal die xkb.tgz an die richtige Stelle entpacken. Zumindest hat das bei mir geholfen. Leider weiß ich aber auch noch nicht, was sich dadurch (durch die Reinstallation von xkeyboard-config) geändert/korrigiert hat.

Habe das schon oft gemacht, um mein altes Layout wiederherzustellen. Allerdings hat das bei mir keinen Einfluss. (Arch GNU/Linux)

[stephan]

Bei mir unter Ubuntu musste ich die rules in die Datei 'evdev' eintragen, anstatt in 'base'. Ob das eine Auswirkung hat, weiß ich nicht. Ansonsten könnte man noch die neuen Dateien aus r1864 und r1865 ausprobieren. Leider existiert hierfür noch kein Archiv.

[erik]

jetzt habe ich den gleichen fehler wie martin. mit der neuen version die aus den vielen dateien besteht. :-( aber bei martin war das ja schon vorher. also muss es an was anderem liegen.

[erik]

So, neueste Erkenntnis: Nachdem ich alle Dateien installiert habe geht es nicht mehr

Fehler: Error loading new keyboard description.

Wenn ich mit

sudo wget http://wiki.neo-layout.org/export/1802/linux/X/de -O /usr/share/X11/xkb/symbols/de

Version r1802 der de-Datei installiere und sonst alle Dateien in der neuen Version lasse, kann ich wieder Neo laden. Allerdings mit den Nachteilen, die es eben bei r1802 gab (keine richtigen Locks).

Der Fehler steckt also in der Datei symbols/de. Naja, oder auch in rules/base, denn dort steckt ja der neue Name Layout de, Variante neo drin.

Stephan, könntest Du das nicht mal bei Dir auf einem sauberen System (virtuelle Maschine) testen? Oder ist dieser Fehler wirklich nur bei Arch und Fedora 10 zu sehen?

[knittl]

ich hab hier ubuntu 9.04, und bis jetzt hat immer alles funktioniert (hatte die dateien als symlinks in meinem system, damit die immer aktuell ausm repo sind)

bekomm aber mittlerweile folgenden fehler:

$ setxkbmap -v 10 de neo
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Warning! Multiple definitions of layout variant
         Using command line, ignoring X server
Applied rules from evdev:
model:      precision_m
layout:     de
variant:    neo
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwertz)
types:      complete
compat:     complete
symbols:    pc+de(neo)+inet(evdev)
geometry:   pc(pc104)
Error loading new keyboard description

neuinstallation von xkb-data behebt das problem – dann hat man aber auch wieder die alte neo version. kann es sein, dass irgendwo versionen spießen, wenn ein paar neue files reinkopiert werden?

[wettstein509@…]

symbols: pc+de(neo)+inet(evdev)

Hier müsste de(neo_base) benutzt werden. Offenbar wird nicht rules/base, sondern ein anderes rules-File benutzt. Stephan hat bereits erwähnt, dass er rules/evdev anpassen musste, ebenfalls mit Ubuntu. Du kannst auch folgendes ausprobieren:

setxkbmap -v 10 de neo_base -option shift:both_capslock,lv3:caps_switch,lv3:bksl_switch,lv5:lsgt_switch_numlock,lv5:ralt_switch_numlock

[stephan]

Ich habe auch einige Tests auf einem frischen Ubuntu 9.04 gemacht. Mittels "setxkbmap de neo" funktioniert r1875 einwandfrei, solange man die Änderungen in den rules nicht nur in base, sondern auch in evdev vornimmt. Mit dem Gnome Settings Manager stürzt der X-Server ab, wenn man mit r1875 + evdev versucht, Neo als Zweitbelegung hinzuzufügen. Soweit ich es erkennen kann, liegt es wirklich an der Umbenennung von 'neo' in 'neo_base'. Scheinbar wird noch von irgendwo auf 'neo' referenziert.

Am Rande: Positiv zu vermerken ist, dass wenn die neuen Optionen in rules/evdev.xml eingetragen werden, können diese jetzt schon ohne Probleme unter Gnome auf beliebige Layouts angewendet werden.

[Markus Rennings]

Ich hab grad auch mal HEAD (r1876) versucht (da ich mit r1810 unter KDE 4.2.87 keine Desktops mehr wechseln konnte (Strg-F1), wenn ich zwei Layouts einbinden wollte), Resultat: Geht nicht :)

Bekomme wie oben den Fehler

Error loading new keyboard description

Die Ausgabe von "setxkbmap -v 10 -option -option grp_led:scroll,grp:shifts_toggle -model microsoftpro -variant neo,nodeadkeys de,de" sieht der obigen ebenfalls ziemlich gleich aus:

Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard model
         Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Warning! Multiple definitions of layout variant
         Using command line, ignoring X server
Applied rules from evdev:
model:      microsoftpro
layout:     de,de
variant:    neo,nodeadkeys
options:    grp_led:scroll,grp:shifts_toggle
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwertz)
types:      complete
compat:     complete+ledscroll(group_lock)
symbols:    pc+de(neo)+de(nodeadkeys):2+inet(evdev)+group(shifts_toggle)
geometry:   microsoft(natural)
Error loading new keyboard description

Mir ist aufgefallen, dass es unter /usr/share/X11/xkb/rules neben der "normalen" Datei base zwei weitere gibt, base.{lst,xml}. Ich weiß jetzt nicht, ob diese auch entsprechend angepasst werden müssen; jedenfalls gehören diese Dateien ebenfalls zum Paket xkeyboard-config.

Mein System: Gentoo Linux, xorg-x11-7.4, xorg-server-1.5.3. Konfiguriert ist die Tastatur über hal mit Treiber evdev

[wettstein509@…]

symbols: pc+de(neo)+de(nodeadkeys):2+inet(evdev)+group(shifts_toggle)

Wie gehabt, da müsste de(neo_base) verwendet werden.

Mir ist aufgefallen, dass es unter /usr/share/X11/xkb/rules neben der "normalen" Datei base zwei weitere gibt, base.{lst,xml}. Ich weiß jetzt nicht, ob diese auch entsprechend angepasst werden müssen; jedenfalls gehören diese Dateien ebenfalls zum Paket xkeyboard-config.

Falls du deine Filesysteme nicht mit «noatime» mountest kannst du dir nach setxkbmap mit «ls -ul rules» die Zugriffszeiten ansehen. Daran siehst du, welche Files gelesen wurden. Bei mir wird das .lst-File durchaus gelesen. Ich vermute trotzdem, dass bei dir das Problem ist wie unter Ubuntu.

[erik]

Tja, also funktioniert es wohl bei niemandem. Man müsste also herausfinden, welche Änderung dazu führt, dass der oben genannte Fehler auftritt.

Ich frage mich andererseits, warum Stephan überhaupt ein neo_base eingeführt hat. Hätte es nicht gereicht mit

include(blubbla);

die ganzen Zusatzdinge direkt bei neo einzubinden? Dann müsste man auch die rules nicht so sehr verändern.

[knittl]

ja, das neo_base verursacht erheblichen mehraufwand. v.a. unter ubuntu müssten dazu noch diverse xml files von evdev geändert werden, meine ich zumindest mich dunkel erinnern zu können.

das beste und einfachste wär vermutlich neo_base wieder in neo umzubenennen, dann sollte es auf allen systemen funktionieren, auf denen neo vorher schon drauf war.

bin schon gespannt wie stephan das lösen wird :) und dann haben wir voll funktionsfähiges neo in X :)

[stephan]

So wie ich das sehe gibt es hier mehrere Probleme. Das ursprüngliche lässt sich einfach umgehen, wenn man auch die evdev ersetzt, oder, wenn man zu faul dafür ist, folgendes ausführt: setxkbmap -v 10 -rules base de neo Ich werde im nächsten Update auch die evdev-Version hochladen, damit es nicht zu Missverständnissen führt.

Zur Umbenennung von 'neo' in 'neo_base': Dies geschah mit dem Hintergedanken, dass der Abschnitt in symbols/de nun nicht mehr einzelnd ein vollwertiges Layout ist. Diese Umbenennung funktioniert auch bestens, solange die korrekte rules-Datei und nicht mehrere Layouts verwendet werden. Ersteres wurde oben bereits behandelt und letzteres habe ich auch nach etlichen Versuchen nicht 100%ig lösen können. Hier macht mir eine Einschränkung der rules zu schaffen (Wird Neo als Zweitbelegung gewählt, so lässt sich nicht verhindern, dass eine Komponente aus symbols mit der Form layout(variant) geladen wird, in dem Fall also de(neo), was allerdings de(neo_base) sein sollte). Deshalb ist es wohl keine schlechte Idee, die Umbenennung rückgängig zu machen.

Mir ist aufgefallen, dass es unter /usr/share/X11/xkb/rules neben der "normalen" Datei base zwei weitere gibt, base.{lst,xml}.

Diese werden von GUIs benutzt, um eine Liste der verfügbaren Layouts, deren Varianten, sowie mögliche Optionen anzuzeigen. Diese Dateien beeinflussen nicht setxkbmap. Unter diesen beiden Dateien ist die .lst-Datei veraltet und wird nur aus Kompatibilitätsgründen aus der xml generiert. Der gnome-settings-manager unter Ubuntu verwendet die evdev.xml.

[anonymous]

Replying to stephan:

Zur Umbenennung von 'neo' in 'neo_base': Dies geschah mit dem Hintergedanken, dass der Abschnitt in symbols/de nun nicht mehr einzelnd ein vollwertiges Layout ist.

Achso, die Idee war, dass man mit neo_base die Belegung der Buchstabentasten hat und dann mittels „-option“ selbst entscheiden kann, wo die Mods liegen oder wie diese festgestellt („gelockt“) werden. Eigentlich eine sehr gute Idee, da es einige Benutzer gibt, die ihre Mods an anderen Stellen (Arno, Stefan) haben oder, wie Neophyt, die Feststellung nur mit einer Umschalttaste lösen wollen.

Aber kann man nicht trotz der includes in de/neo Optionen übergeben? Was hat Priorität?

PS: Ich mag die neuen Captchas. Endlich lerne ich Kopfrechnen. ;-)

[stephan]

Ich frage mich andererseits, warum Stephan überhaupt ein neo_base eingeführt hat. Hätte es nicht gereicht mit {{{ include(blubbla); }}} die ganzen Zusatzdinge direkt bei neo einzubinden? Dann müsste man auch die rules nicht so sehr verändern.

Ich werde das mal testweise umsetzen.

Aber kann man nicht trotz der includes in de/neo Optionen übergeben? Was hat Priorität?

Eigentlich sollten Optionen trotzdem übergeben werden können, allerdings würden die Modifier dann eventuell mehrmals von den Optionen überschrieben werden, was unschön ist und auch nicht immer das gewünschte Ergebnis hervorbringt. Mit den jetzigen Optionen sollte es aber gut funktionieren, noch sehe ich da keine Probleme.

Wenn ich das richtig verstehe gibt es da keine festgelegte Prioritäten, es wird wie bereits erwähnt wahllos überschrieben. Zwar können bestimmte Anweisungen (replace, override) vor den Definitionen, oder die Verwendung von 'augment' anstatt 'include' dieses Verhalten steuern, aber damit bin ich bisher nie richtig zurecht gekommen.

Eine gute Methode, um zu überprüfen, wie das abläuft bietet z.B.:

setxkbmap de neo -option XXX -print | xkbcomp - -xkb test.xkb

XXX muss mit der gewünschten Option ersetzt werden (z.B. "shift:both_shiftlock"). Dies generiert eine test.xkb, welche die komplette keymap enthällt. Dort kann man dann feststellen, wie die Optionen Einfluss auf das Endergebnis nehmen.

[erik]

Ah, die zuletzt in diesem Ticket aufgeführten Fehler rühren wohl von einem Vertipper in der de-Datei. Siehe die Änderung in dieser Datei in r1877:  Hier in Zeile 265 bzw. 271.

Mit der neuen Version habe ich allerdings wieder Probleme, wenn ich basic und neo gleichzeitig lade. So geladen:

setxkbmap -layout "de,de" -variant "basic,neo" -option "grp:lwin_toggle,grp_led:scroll" -model pc105

Dieses mal funktioniert AltGr und Umschalt bei QWERTZ nicht. Und bei Neo funktionieren die Zahlen auf Ebene 4 nicht.

Mein System: Fedora 10.

Wenn ich neo einzeln lade, gibt es keine Probleme.

[Markus Rennings]

r1877 funktioniert soweit wieder, wie es soll. Hierbei ist mir nur aufgefallen, dass es Probleme mit nodeadkeys gibt, wenn man dieses als 2. Layout lädt:

setxkbmap -v 10 -option -option grp_led:scroll,grp:alt_space_toggle -model microsoftpro -variant neo,nodeadkeys de,de

Ich kann hier problemlos zwischen beiden Layouts umschalten, jedoch funktioniert unter nodeadkeys die Alt-Gr- und die <>-Taste nicht mehr. Auch die Tastenkombination für den Neo-CapsLock (Shift-Shift) bleibt unter nodeadkeys erhalten.

xev zeigt unter Neo für Alt-Gr und <> (keysym 0xff7f, Num_Lock) an, unter nodeadkeys für Alt-Gr (keysym 0xfe03, ISO_Level3_Shift), für <> wie gehabt (keysym 0xff7f, Num_Lock). (Die <>-Taste funktionierte in r1810 schon nicht mehr richtig, wimre.)

Wenn ich nur "setxkbmap -v 10 -option -model microsoftpro -variant nodeadkeys de" lade, funktionieren alle Tasten, wie sie sollen.

[stephan]

Replying to Markus Rennings:

r1877 funktioniert soweit wieder, wie es soll. Hierbei ist mir nur aufgefallen, dass es Probleme mit nodeadkeys gibt, wenn man dieses als 2. Layout lädt: {{{ setxkbmap -v 10 -option -option grp_led:scroll,grp:alt_space_toggle -model microsoftpro -variant neo,nodeadkeys de,de }}}

Mit r1879 sollte das ganze besser klappen. Allerdings wird die <>-Taste weiterhin nicht gehen, wenn du neo als erstes Layout einstellst, da diese Taste nicht in symbols/de definiert wird und somit die Neo-Belegung nicht überschreibt. Ich schlage deshalb vor, Neo als letztes Layout zu laden. Einige weitere Tasten sind dadurch soweit ich weiß auch betroffen.

[erik]

Unter Fedora 11 hatte ich us als Standardbelegung und habe dann unter Gnome neo als Zweitbelegung eingestellt. Das hatte zur Folge, dass ich unter Neo beim Drücken auf Mod4rechts das Verhalten hatte, als würde ich die normale Alt-Taste und die Cursortasten drücken (wenn ich auf Mod4 und iael gedrückt habe).

[erik]

Ah, so ein Mist. Mit der neuen Version (r1885) kann ich mich nicht mehr anmelden. Ich nutze Fedora 10 und kann daher im GDM (wie bei jedem aktuellen System ⇔ Ubuntu ist da veraltet) auswählen, welche Tastaturbelegung der anzumeldende Benutzer verwendet. Mit Neo kann ich mein Passwort nicht mehr eingeben. Ich weiß nicht was schief läuft, aber ich komme nicht rein, auch nicht, wenn ich es QWERTZig (also die Zeichen eingebe, wie sie auf der QWERTZ-Tastatur stehen) eingebe. Wenn ich aber QWERTZ als Tastaturbelegung wähle, kann ich mein Passwort QWERTZig eingeben.

[stephan]

Funktioniert es, wenn du bei der Eingabe auf die Zeichen der 4ten Ebene verzichtest?

Eigentlich kann ich mir nicht vorstellen, dass sich mit r1885 etwas groß verändert haben sollte und wenn doch, so ist das wohl wieder einer der unzähligen Mythen des xkb-Systems. Wenn es nicht bald gelöst ist, lege ich mir auch mal Fedora zu, um selbst herumexperimentieren zu können.

[anonymous]

Replying to stephan:

Funktioniert es, wenn du bei der Eingabe auf die Zeichen der 4ten Ebene verzichtest?

Nein, leider auch nicht.

Eigentlich kann ich mir nicht vorstellen, dass sich mit r1885 etwas groß verändert haben sollte und wenn doch, so ist das wohl wieder einer der unzähligen Mythen des xkb-Systems.

Hätte ich auch nicht gedacht. Kann das jemand nachvollziehen, oder habe nur ich das Problem?

Wenn es nicht bald gelöst ist, lege ich mir auch mal Fedora zu, um selbst herumexperimentieren zu können.

Oder so … ;-)

[aleχ]

Hallo,

also ich habe jetzt auch mal auf die aktuellste Version gewechselt (hatte vorher die Version ohne Locks, welche einwandfrei funktioniert hatte) und nun geht Ebene 6 nicht mehr richtig, bei den Navigationszeichen 4vlcwuiaeoä reagiert er so wie in Ebene4, alle anderen Zeichen, auch üö (∪∩) funktionieren prima.

Habe Gentoo, x11-base/xorg-server-1.6.1.901-r4, und auch das config-paket auf Version 1.6.

[aleχ]

Huch, als Ergänzung etwas merkwürdig: Das Problem tritt in kwrite auf, nicht aber in xev, oowriter, konsole. Kann mir nicht vorstellen, wie dieser Bug zustande kommt.

[stephan]

Replying to erik:

Ah, so ein Mist. Mit der neuen Version (r1885) kann ich mich nicht mehr anmelden. Ich nutze Fedora 10 und kann daher im GDM (wie bei jedem aktuellen System ⇔ Ubuntu ist da veraltet) auswählen, welche Tastaturbelegung der anzumeldende Benutzer verwendet. Mit Neo kann ich mein Passwort nicht mehr eingeben. Ich weiß nicht was schief läuft, aber ich komme nicht rein, auch nicht, wenn ich es QWERTZig (also die Zeichen eingebe, wie sie auf der QWERTZ-Tastatur stehen) eingebe. Wenn ich aber QWERTZ als Tastaturbelegung wähle, kann ich mein Passwort QWERTZig eingeben.

Ich entschuldige mich für die lange Bearbeitungsdauer, aber ich hatte das leider total vergessen. Fedora 10 habe ich wegen einer Inkompatibilität nicht installiert bekommen, aber unter Fedora 11 konnte ich das Problem nicht nachvollziehen: Ich habe den xkb-Treiber ganz normal installiert und bei der nächsten Anmeldung mich mit dem Neo-Layout angemeldet (Im Anmeldebildschirm unten ausgewählt). Das Passwort enthielt Zeichen der ersten 4 Neo-Ebenen und ich konnte mich ohne Probleme anmelden. Auch nach der Anmeldung funktioniert Neo wie erwartet.

Ist das ein Fedora 10-spezifisches Problem?

[erik]

Replying to stephan:

Replying to erik:

Ah, so ein Mist. Mit der neuen Version (r1885) kann ich mich nicht mehr anmelden. Ich nutze Fedora 10 und > Ich entschuldige mich für die lange Bearbeitungsdauer, aber ich hatte das leider total vergessen.

Fedora 10 habe ich wegen einer Inkompatibilität nicht installiert bekommen, aber unter Fedora 11 konnte ich das Problem nicht nachvollziehen: Ich habe den xkb-Treiber ganz normal installiert und bei der nächsten Anmeldung mich mit dem Neo-Layout angemeldet (Im Anmeldebildschirm unten ausgewählt). Das Passwort enthielt Zeichen der ersten 4 Neo-Ebenen und ich konnte mich ohne Probleme anmelden. Auch nach der Anmeldung funktioniert Neo wie erwartet. Ist das ein Fedora 10-spezifisches Problem?

Hmm, habe nun auch Fedora 11. Was für ein altes ungelöstes Ticket. :-) Werde es gleich mal testen. … Oh, funktioniert. Hmm, muss das Ticket nochmal schnell überfliegen, was es da noch so für Probleme gab.

Ah,  Kommentar 21. Also es ist besser als damals. Mit

setxkbmap -layout "de,de" -variant "basic,neo" -option "grp:ctrl_shift_toggle,grp_led:scroll"

gibt es jetzt nur noch das Problem, dass die 4. und 6. Ebene von Neo nicht funktioniert (stattdessen erscheint die 1. und 3.).

Also immer noch nichts mit Umschalten. Schade, denn eigentlich war diese Umschaltfunktion sehr praktisch.

Sollen wir dieses Ticket mal schließen? Es vereint momentan ja mehrere Probleme, wovon inzwischen nur noch die durch’s Umschalten ausgelösten übrig bleiben. Achso, und das von aleχ beschriebene alt bekannte, bei dem ich nur weiß, dass es entweder mit KDE hakt, oder woanders.

Grüße, Erik

[stephan]

Ich denke, wir sollten das Ticket schließen und einzelne Tickets für die verschiedenen Probleme eröffnen.

Soweit ich sehen kann gibt es folgende Probleme, für die noch kein eigenes Ticket existiert:

1. Wenn Neo als Zweitlayout eingerichtet ist, funktioniert Neo-Mod4 (also die Ebenen 4 und 6) nicht mehr.

2. Wenn Neo als Erstlayout zusammen mit einem anderen Zweitlayout eingerichtet ist, treten Probleme beim Zweitlayout auf: Caps-Lock ist immernoch wie in Neo belegt, „<“-Taste ist immernoch wie in Neo belegt, etc. Diese Probleme beruhen aber auch teilweise auf Einschränkungen in xkb. Alle Probleme werden sich wohl nicht lösen lassen.

3. Probleme von aleχ: vlcwuiaeoä verhalten sich in xev auf Ebene6 wie die jeweiligen Navigationstasten in Ebene4

4. Tastaturkürzel, wie Strg + C beruhen immer auf der Tastenbelegung des ersten Layouts, sind mehrere eingestellt richten sich also alle immer nach der Belegung des ersten Layouts. (#169 fasst soweit ich das sehen kann ein anderes Problem mit den Funktionstasten auf)

Wenn es in Ordnung ist, würde ich für alle Probleme ein einzelnes Ticket mit einer etwas detaillierteren Fehlerbeschreibung aufmachen.

[Peter Eberhard <drahrebep@…>]

Replying to stephan:

Ich denke, wir sollten das Ticket schließen und einzelne Tickets für die verschiedenen Probleme eröffnen. Soweit ich sehen kann gibt es folgende Probleme, für die noch kein eigenes Ticket existiert: 1. Wenn Neo als Zweitlayout eingerichtet ist, funktioniert Neo-Mod4 (also die Ebenen 4 und 6) nicht mehr.

Hoffentlich gelöst, siehe Mailingliste.

2. Wenn Neo als Erstlayout zusammen mit einem anderen Zweitlayout eingerichtet ist, treten Probleme beim Zweitlayout auf: Caps-Lock ist immernoch wie in Neo belegt, „<“-Taste ist immernoch wie in Neo belegt, etc. Diese Probleme beruhen aber auch teilweise auf Einschränkungen in xkb. Alle Probleme werden sich wohl nicht lösen lassen.

Das ist ein Problem von xkbconfig. In symbols/pc stehen diese Tasten unter dem Kommentar “these keys are common to all layouts”. Das ist nun halt seit Neo nicht mehr so. Und symbols/pc gilt eben für alle Gruppen gleichzeitig, in rules/base steht für die zweite Gruppe &c. immer +%l[2]%(v[2]):2 statt +pc:2+%l[2]%(v[2]):2, was dieses Problem wohl ebenfalls lösen würde. Jedenfalls das CapsLock- und <>|-Problem. Damit ergibt sich aber immerhin ein Workaround, indem man die rules umgeht und die symbols,geometry,keycodes,compat,types von Hand angibt. Sowas müsste dann ins Wiki, nachdem das einer getestet hat.

3. Probleme von aleχ: vlcwuiaeoä verhalten sich in xev auf Ebene6 wie die jeweiligen Navigationstasten in Ebene4

Das ist wohl dasselbe Problem wie 1. Nachdem ich 1. gelöst habe, geht es bei mir.

4. Tastaturkürzel, wie Strg + C beruhen immer auf der Tastenbelegung des ersten Layouts, sind mehrere eingestellt richten sich also alle immer nach der Belegung des ersten Layouts. (#169 fasst soweit ich das sehen kann ein anderes Problem mit den Funktionstasten auf)

Das kommt scheinbar auf das Programm an. Terminal nimmt bei mir immer das erste Layout, gedit komischerweise beide (jedenfalls für Strg-x,c,v, da gibt es wohl einen Vorrang für manche Kombis). Da bleibt uns wohl nur wontfix übrig.

Wenn es in Ordnung ist, würde ich für alle Probleme ein einzelnes Ticket mit einer etwas detaillierteren Fehlerbeschreibung aufmachen.

Wäre wohl angebracht. Evtl. 3. mit zu 1. legen. Falls das mit Neo als sekundäres Layout zusammenhing (geht aus Alex’ Meldung nicht hervor).

[stephan]

Das erste Problem hat folgendes Ticket erhalten: #174

Das zweite Problem: #175

Problem 3 kann (falls es noch auftritt) dem Ticket #174 angehängt werden.

Komischerweise kann ich das 4. Problem momentan nicht reproduzieren, bin mir aber sicher, dass es vor einigen Monaten aufgetreten ist. Ich habe für dieses Problem deshalb noch kein Ticket erstellt.