Neue xkbmap-Version setzt xkbmap außer Gefecht #141
Labels
No Label
(╯°□°)╯︵ ┻━┻
Bug
Diskussion
Dokumentation
Duplikat
Gitea
Hardware
Hilfe
Invalid
Java
Lernen
Qt
Remote
Subversion
Tablet
Tastaturbelegung
Test
Treiber/Android
Treiber/iOS
Treiber/Linux/Konsole
Treiber/Linux/xkb
Treiber/Linux/xmodmap
Treiber/MacOS
Treiber/Windows/AHK
Treiber/Windows/kbdneo
Treiber/Windows/ReNeo
Verbesserung
Website
Windows 11
Wontfix
Worksforme
No Milestone
No Assignees
9 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: neo/neo-layout#141
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bei
setxkbmap <*>
erscheint nur folgende Fehlermeldung:Couldn't find rules file (xorg)
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:
Fehlermeldung jetzt:
Error loading new keyboard description
Damit funktioniert es einwandfrei. Um diese Rechte zu erreichen solltest Du eingeben:
Funktioniert es jetzt wieder?
Ich konnte damals, als der Fehler auftrat, trotzdem im Nachhinein mit
auf Neo wechseln.
r1860 ist ein Versuch das zu beheben. Klappt’s?
Rechte stimmen jetzt. Aber die xkbmap kann ich immer noch nicht laden :(
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)
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.
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.
So, neueste Erkenntnis:
Nachdem ich alle Dateien installiert habe geht es nicht mehr
Fehler:
Error loading new keyboard description
.Wenn ich mit
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 inrules/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?
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:
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?
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:
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.
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
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:
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
Wie gehabt, da müsste de(neo_base) verwendet werden.
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.
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
die ganzen Zusatzdinge direkt bei neo einzubinden? Dann müsste man auch die rules nicht so sehr verändern.
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 :)
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.
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.
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. ;-)
Ich werde das mal testweise umsetzen.
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.:
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.
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:
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.
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:
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.
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.
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).
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.
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.
Hätte ich auch nicht gedacht. Kann das jemand nachvollziehen, oder habe nur ich das Problem?
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.
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.
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?
Ah, Kommentar 21. Also es ist besser als damals. Mit
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
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:
Wenn Neo als Zweitlayout eingerichtet ist, funktioniert Neo-Mod4 (also die Ebenen 4 und 6) nicht mehr.
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.
Probleme von aleχ: vlcwuiaeoä verhalten sich in xev auf Ebene6 wie die jeweiligen Navigationstasten in Ebene4
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.
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.
Das ist wohl dasselbe Problem wie 1. Nachdem ich 1. gelöst habe, geht es bei mir.
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).
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.