Anleitung zu eigenen Keyboard-Layout bei Linux #40
hrnz
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Schmiddiii/dokumentation:linux-xkb-own-layout"
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?
Habe ich bei mir lokal so gemacht, sollte also auch so in den meisten
Distributionen funktionieren. Es sind vielleicht noch einige
Rechtschreibfehler/Grammatikfehler dabei.
Erstmal danke für den Beitrag,
allerdings finde ich persönlich die beschrieben Methode nicht sehr gut. Denn meiner Meinung nach ist eine Vorgehensweise besser, bei der man die Definitionen in
/usr/share/X11/xkb/symbols/denimmt (Z.B. die von Neo) und diese für die eigenen Zwecke modifziert (Wobei die beschriebene Methode auch nicht total idiotisch ist).Es wäre auch gut, zu erwähnen, dass diese Methode mit Xorg und Wayland funktioniert, dass man aber auf Xorg auch mit xkbcomp das Layout laden kann. Des weiter wäre es gut noch einen Stub für die Konfiguration der Tastatur auf der Konsole zu erstellen (und dort auf kmscon zu verweisen).
Zusätzlich wäre ein Hinweis auf kmscon/keyd auch noch hilfreich.
Die meisten dieser Dinge können natürlich in einem anderen PR verarbeitet werden, aber ich wollte dich nur mal vorgewahnt haben, dass ich da möglicherweise noch ein wenig dran rumbauen werde ;)
Die Definition von
/usr/share/X11/xkb/symbols/dezu nehmen ist vielleicht nicht schlecht. Ich hab es so gemacht, da es in den von euch verlinkten Stackoverflow so beschrieben wurde.Ich habe es persönlich nur auf Xorg getestet, für Wayland kann ich nicht bürgen.
Von
kmsconundkeydhabe ich noch nie gehört, kann also auch davon eher weniger schreiben.Habe jetzt die Methode angepasst wie du es (hoffentlich) gemeint hast. Da das finde ich ein wenig komplexer zu erklären ist, habe ich noch eine Beispiel in einen ausklappbaren Bereich angehängt (mit hoffentlich korrekter MkDocs-Syntax).
Ich würde sehr davon abraten, manuell irgendwie in Dateien rumzupfuschen, die von der Paketverwaltung kontrolliert werden. Das kann nur Ärger geben.
Der bevorzugte Weg, in 2022 auf dem GANOO/Loonix-Desktop eigene Tastaturbelegungen zu konfigurieren, ist xkb-Overlays in
${XDG_CONFIG_HOME:-~/.config}/xkb(benutzerspezifisch) oder/etc/xkb(systemspezifisch) zu verwenden. Möchte man also eine Varianteneoqwertz_nodeadkeyszu de hinzufügen, erstellt man eine Datei~/.config/xkb/symbols/demit dem entsprechendem Snippet. Damit die Variante auch in der Tastaturbelegungsliste (via libxkbregistry) auftaucht, kann man die Variante in der Datei~/.config/xkb/rules/evdev.xmlregistrieren, etwa mitDer Benutzer-xkb-Baum erweitert den System-Baum, der den Vendor-Baum erweitert. Man muss nicht alle Varianten kopieren und includes funktionieren trotzdem.
Kleiner Nachteil: Das funktionierte nicht mit dem Legacy-Display-Server, wobei ich mir nicht sicher bin, ob das in 2022 noch wichtig ist (Mittlerweile sollten ja alle relevanten Distros standardmäßig Wayland/libxkbcommon benutzen).
Mit X11 gibt es keine sinnvolle Möglichkeit, Benutzerlayouts zu konfigurieren. Man kann irgendwie hässlich mit xkbcomp das aktuell geladene Layout ersetzen (bäh) oder im Vendor-Tree rumfummeln (bäh).
Die noch beste Lösung ist, im Vendor-Tree ein Layout mit dem Namen
custom(basic)zu erstellen, da dieses schon einen Eintrag in evdev.xml besitzt, es jedoch keine Datei dafür gibt, also die Änderungen nicht immer wieder von der Paketverwaltung überschrieben werden würde. Eigene Layouts mit anderem Namen sind prinzipiell auch möglich (die Standard-Regelmenge hat Wildkartenregeln dafür), diese erscheinen aber nicht in den graphischen Tastatureinstellungen).Dazu noch ein wunderbares Peter Hutterer (der übrigens ausgezeichnete Blogposts zur xkb-Konfiguration hat)-Zitat:
@hrnz Leider gibt es noch viele Fensterverwalter, welche noch immer X11 verwenden und für die es noch keine guten Alternativen gibt (bsp. XMonad). Daher ist auch die Konfiguration in Xorg noch relevant.
Meint ihr nicht, dass es dann besser wäre das in eine eigene Seite auszulagern, wenn es für verschiedene Systeme verschieden zu machen ist, und dann vielleicht noch
keydundkmsconerwähnt werden sollte? Es ist ja jetzt schon ziemlich lange und eigentlich ein vollkommen optionaler Schritt bei der Einrichtung unter Linux. Und vielleicht wäre in Zukunft dann noch ein eigenes Layout auf Mac oder Windows interessant (da kann ich aber nicht helfen).Und die Frage ist, ob es überhaupt erwähnt werden sollte wie man es anpassen kann. Ist Anpassbarkeit ein Kern-Feature von Neo? Wenn nicht wäre die Information vielleicht eher auf einer anderen Website geeigneter.
Über solche Fragen kann ich aber nicht entscheiden.
@Schmiddiii Also ich denke das hat schon Platz auf unserer Website, da viele ihr Layout nochmal an ihr Gerät anpassen und Neo ja gewissermaßen auch ein Projekt ist, bessere Belegungen zu finden. Eine zentrale Seite für Tastaturkonfiguration wäre vermutlich gut, wobei es schon https://neo-layout.org/Beitragen/Treiber-KnowHow/, was diesen Anspruch schon etwas abdeckt (wobei es nicht sehr anfängerfreundlich ist)
@ -338,2 +336,3 @@Das Erstellen eines eigenen Layouts ist nicht so schwer wie man anfangs denken mag. Jedoch benötigt man dafür einige Kenntnisse mit der Kommandozeile. Es wird im Beispiel gezeigt, dass Tote Tasten aus dem NeoQwertz zu normalen Tasten umgeändert werden. Dies sollte sowohl unter Xorg als auch unter Wayland funktionieren.Siehe auch:Zuerst sollte eine Basis erschaffen werden, auf der dann die Änderung durchgeführt werden kann. Man betrachte dafür die Datei `/usr/share/X11/xkb/symbols/de` und suche nach unserem gewünschten Basis-Layout, hier `neo_qwertz` und kopiert dies in eine eigene Datei, welche ungefähr wie folgt aussieht:Wäre es für dieses Beispiel nicht einfacher,
include "de(neo_qwertz)"in das neue Layout-Segment zu schreiben anstatt alles zu kopieren?@ -340,0 +373,4 @@Außerdem müssen `tilde` und `circumflex` durch `asciitilde` und `asciicircum` bei den jeweiligen Tasten ausgetauscht werden.Nun ist das erstellte Layout bereits fertig, es muss nun nach `/usr/share/X11/xkb/symbols/` verschoben werden, zum Beispiel mit den Namen `neo_qwertz_nodeadkeys` (es werden Root-Rechte benötigt) und das erstellte Layout kann mit `setxkbmap neo_qwertz_nodeadkeys` geladen werden. Alternativ kann die Datei unter Xorg auch ohne Root-Rechte mithilfe von `xkbcomp <dateiname> $DISPLAY` geladen werden. Falls ein Fehler beim Editieren der Datei gemacht wird, wird man hier darauf hingewiesen, das Tastaturlayout ändert sich nicht und man kann die Fehler korrigieren. Falls man seinen Fehler nicht findet, kann man durch `xkbcomp <dateiname>` auch das erstellten Layout prüfen lassen.setxkbmap ist auch x11-spezifisch, die Formulierung klingt so, als wäre das universell.
Wie funktionert es dann in Wayland? Habe Wayland noch nie genutzt.
Die Antwort auf alle Fragen in der Wayland-Welt ist "es ist compositor-abhängig". Wir haben allerdings für die meisten wichtigen Compositors schon eine Anleitung. Und der ganze Witz an der Sache ist ja, dass es man eigene Layouts dann genauso konfigurieren kann wie die bereits vorhandenen
@ -340,0 +378,4 @@??? example "Beispiel"```partial alphanumeric_keys modifier_keys keypad_keysxkb_symbols "neo_quertz_nodeadkeys" {quertz -> qwertz
kmscon könnte man irgendwo erwähnen, hat imho aber nichts mit dieser Änderung zu tun. Ich denke nicht, dass wir irgendwas zu keyd sagen sollten, da es vollkommen ungeeignet ist, um das Neo-Layout zu implementieren. Schließlich kombiniert es im Wesentlichen nur die Nachteile von richtigen Tastaturbelegungen mit denen von Tastaturfirmwarefrickelkacke à la QMK.
nun ja, gute Alternativen haben notwendigerweise sehr wenig mit XMonad gemeinsam (scnr)
Ich denke, es wäre vorteilhaft, in dieser Anleitung auch das
custom-Layout zu benutzen, damit nicht die Installationsanleitungen alle invalidiert werden.Sieht ansonsten gut aus.
Bin mir nicht sicher, wie ich das korrekt überprüfen kann, aber Linux Mint Cinnamon verwendet anscheinend kein libxkbcommon (zumindest taucht es nicht in der Liste installierter Packages auf). Ich halte Mint schon für relevant.
Generell scheint es nun zwar einfacher zu sein, eigene Layouts oder Optionen in seinem Home-Verzeichnis zu definieren. Trotzdem halte ich das ganze weiterhin für einen riesigen Flickenteppich, und es ist nicht einfach so möglich, bspw. eine Option in symbols hinzuzufügen: https://who-t.blogspot.com/2020/02/user-specific-xkb-configuration-part-1.html
Wenn ich erst das ganze Plumping verstehen muss, um wirksam Sachen zu ändern, vergeht mir doch die Lust daran. Ich habe jetzt eine Stunde probiert, eine Option für die dämlich positionierten Thinkpad-Tasten einzubauen (damit die nicht mehr Forward/Back ausführen, sondern Page Up/Down) und habe es nicht geschafft über eine Custom Konfig. Ich änder das jetzt in
symbols/inet, dann funktioniert es wenigstens.libxkbcommon ist unter anderem eine Abhängigkeit von Gtk und Qt (sowie quasi allen anderen Programmen, die irgendwie irgendwas mit Tastatur machen). Mint wird libxkbcommon schiffen. Vielleicht pullen sie einen Ubuntu/Debian und benennen es aus sehr guten Gründen um.
Jeder Wayland-Compositor jemals nutzt libxkbcommon, um die Layouts zusammenzusuchen und zu lesen. X11 nutzt libxkbcommon nicht (aber quasi alle modernen Anwendungen, die auf X11 laufen, nutzen libxkbcommon, um die Keymap vom xorg-server einzulesen und den Events die Keysyms zuzuordnen).
Ich halte Mint nicht für relevant, aber das ist eine andere Sache.
Optionen haben keine Wildkartenregelungen, weshalb man sie zusätzlich registrieren muss. Ich sehe aber auch keinen Grund, warum irgendjemand eigene Optionen erfinden wollen würde.
Ich würde dafür nicht das Tastaturlayout zerfrickeln, sondern das Scancode→Keycode-mapping dieser Tastatur anpassen. Das hier funktioniert für mich, siehe auch Bogenlinux-Wiki-Artikel.
Ich denke, um bei möglichst geringer Komplexität viele Möglichkeiten abzudecken ist es am besten, wenn wir einfach sagen:
/usr/share/X11/xkb/symbols/customschreibenDas ist zwar nicht ganz so schön wie die User/System-Trees mit richtigen Layout-Namen zu verwenden, funktioniert aber auch mit X11 und man hat keine Probleme mit "Die Paketverwaltung macht meine Änderungen immer wieder rückgängig".
Die Verlinkung auf die Diskussion hier kann dann wieder weg und alles ist einheitlich und vergleichsweise einfach. Die Umstellung auf „richtige” eigene Tastaturbelegungen können wir dann ja in 5 Jahren nochmal versuchen, wenn X11 endlich mausetot ist.
(ich gehe jetzt noch schnell einkaufen, wenn niemand gemeckert hat, bis ich wieder zurück bin, schreib ich das noch so über die Anleitung und fusioniere die Ziehanfrage mit dem Hauptzweig)
Hm,
libxkbcommonist wohl installiert, aber genauso ist eslibwayland… Als Abhängigkeit des Fenstermanagers sehe ich das allerdings nicht. Jedenfalls funktioniert die Erweiterung über~/.config/xkbnicht, weswegen mir da wenig übrigbleibt, als in/usr/share/X11/xkbrumzubasteln.Die detaillierte Beschreibung über das
custom-Layout ist für mich in Ordnung. Es soll schließlich nur verdeutlichen, wie ein eigenes Layout funktioniert oder man eines erweitern kann. Die Details zur Umsetzung sind dann leider wieder sehr vielfältig.Ah, das wird vermutlich auch gehen. Also noch eine Ebene tiefer, interessant. Führt beides zum selben Ziel, aber die Methode mit dem Scancode ist wohl passender.
Hach, ich hab mich verdrückt und jetzt sind die Eltern falsch rum und Gitea zeigt den Pull-Request nicht als gemergt an und alles ist kacke. seufz
Egal, ist drin. Danke nochmal für die schöne Anleitung!
Pull request closed