Anleitung zu eigenen Keyboard-Layout bei Linux #40

Closed
Schmiddiii wants to merge 0 commits from Schmiddiii/dokumentation:linux-xkb-own-layout into master
First-time contributor

Habe ich bei mir lokal so gemacht, sollte also auch so in den meisten
Distributionen funktionieren. Es sind vielleicht noch einige
Rechtschreibfehler/Grammatikfehler dabei.

Habe ich bei mir lokal so gemacht, sollte also auch so in den meisten Distributionen funktionieren. Es sind vielleicht noch einige Rechtschreibfehler/Grammatikfehler dabei.
Schmiddiii added 1 commit 2022-02-16 14:54:47 +01:00
Habe ich bei mir lokal so gemacht, sollte also auch so in den meisten
Distributionen funktionieren. Es sind vielleicht noch einige
Rechtschreibfehler/Grammatikfehler dabei.
Member

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/de nimmt (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 ;)

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/de` nimmt (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 ;)
Author
First-time contributor

Die Definition von /usr/share/X11/xkb/symbols/de zu 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 kmscon und keyd habe ich noch nie gehört, kann also auch davon eher weniger schreiben.

Die Definition von `/usr/share/X11/xkb/symbols/de` zu 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 `kmscon` und `keyd` habe ich noch nie gehört, kann also auch davon eher weniger schreiben.
Schmiddiii added 1 commit 2022-02-16 16:19:04 +01:00
Author
First-time contributor

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).

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).
Owner

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 Variante neoqwertz_nodeadkeys zu de hinzufügen, erstellt man eine Datei ~/.config/xkb/symbols/de mit dem entsprechendem Snippet. Damit die Variante auch in der Tastaturbelegungsliste (via libxkbregistry) auftaucht, kann man die Variante in der Datei ~/.config/xkb/rules/evdev.xml registrieren, etwa mit

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xkbConfigRegistry SYSTEM "xkb.dtd">
<xkbConfigRegistry version="1.1">
  <layoutList>
    <layout>
      <configItem>
        <name>de</name>
      </configItem>
      <variantList>
        <variant>
          <configItem>
            <name>neoqwertz_nodeadkeys</name>
            <shortDescription>neoqwertz nodeadkegs</shortDescription>
            <description>German (NeoQwertz without dead keys)</description>
          </configItem>
        </variant>
      </variantList>
  </layout>
  </layoutList>
</xkbConfigRegistry>

Der 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:

So as a summary: if you want custom keymaps on your machine, switch to Wayland (and/or fix any remaining issues preventing you from doing so) instead of hoping this will ever work on X

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 Variante `neoqwertz_nodeadkeys` zu de hinzufügen, erstellt man eine Datei `~/.config/xkb/symbols/de` mit dem entsprechendem Snippet. Damit die Variante auch in der Tastaturbelegungsliste (via libxkbregistry) auftaucht, kann man die Variante in der Datei `~/.config/xkb/rules/evdev.xml` registrieren, etwa mit ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xkbConfigRegistry SYSTEM "xkb.dtd"> <xkbConfigRegistry version="1.1"> <layoutList> <layout> <configItem> <name>de</name> </configItem> <variantList> <variant> <configItem> <name>neoqwertz_nodeadkeys</name> <shortDescription>neoqwertz nodeadkegs</shortDescription> <description>German (NeoQwertz without dead keys)</description> </configItem> </variant> </variantList> </layout> </layoutList> </xkbConfigRegistry> ``` Der 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: > So as a summary: if you want custom keymaps on your machine, switch to Wayland (and/or fix any remaining issues preventing you from doing so) instead of hoping this will ever work on X
Member

@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.

@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.
Author
First-time contributor

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 keyd und kmscon erwä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.

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 `keyd` und `kmscon` erwä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.
Member

@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)

@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)
hrnz requested changes 2022-02-17 18:40:06 +01:00
@ -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:
Owner

Wäre es für dieses Beispiel nicht einfacher, include "de(neo_qwertz)" in das neue Layout-Segment zu schreiben anstatt alles zu kopieren?

Wäre es für dieses Beispiel nicht einfacher, `include "de(neo_qwertz)"` in das neue Layout-Segment zu schreiben anstatt alles zu kopieren?
Schmiddiii marked this conversation as resolved
@ -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.
Owner

setxkbmap ist auch x11-spezifisch, die Formulierung klingt so, als wäre das universell.

setxkbmap ist auch x11-spezifisch, die Formulierung klingt so, als wäre das universell.
Author
First-time contributor

Wie funktionert es dann in Wayland? Habe Wayland noch nie genutzt.

Wie funktionert es dann in Wayland? Habe Wayland noch nie genutzt.
Owner

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

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
hrnz marked this conversation as resolved
@ -340,0 +378,4 @@
??? example "Beispiel"
```
partial alphanumeric_keys modifier_keys keypad_keys
xkb_symbols "neo_quertz_nodeadkeys" {
Owner

quertz -> qwertz

quertz -> qwertz
Schmiddiii marked this conversation as resolved
Owner

Zusätzlich wäre ein Hinweis auf kmscon/keyd auch noch hilfreich.

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.

für die es noch keine guten Alternativen gibt (bsp. XMonad)

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.

> Zusätzlich wäre ein Hinweis auf kmscon/keyd auch noch hilfreich. 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. > für die es noch keine guten Alternativen gibt (bsp. XMonad) 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.
Owner

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).

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.

> 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). 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.
Schmiddiii added 1 commit 2022-02-18 15:41:02 +01:00
Owner

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).

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).

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 schon für relevant.

Ich halte Mint nicht für relevant, aber das ist eine andere Sache.

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

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.

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.

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.

> > 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). > > 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). 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 schon für relevant. Ich halte Mint nicht für relevant, aber das ist eine andere Sache. > 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 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. > 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. Ich würde dafür nicht das Tastaturlayout zerfrickeln, sondern das Scancode→Keycode-mapping dieser Tastatur anpassen. [Das hier](https://git.hrnz.li/Ulli/nixos/src/branch/main/profiles/keyboard/default.nix#L23) funktioniert für mich, siehe auch [Bogenlinux-Wiki-Artikel](https://wiki.archlinux.org/title/Map_scancodes_to_keycodes#Example_for_custom_hwdb).
Owner

Ich denke, um bei möglichst geringer Komplexität viele Möglichkeiten abzudecken ist es am besten, wenn wir einfach sagen:

  • Das neue Layout in die Datei /usr/share/X11/xkb/symbols/custom schreiben
  • Das "custom" Layout dann genauso wie in der Installationsanleitung einstellen.

Das 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)

Ich denke, um bei möglichst geringer Komplexität viele Möglichkeiten abzudecken ist es am besten, wenn wir einfach sagen: - Das neue Layout in die Datei `/usr/share/X11/xkb/symbols/custom` schreiben - Das "custom" Layout dann genauso wie in der Installationsanleitung einstellen. Das 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)
Owner

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.

Hm, libxkbcommon ist wohl installiert, aber genauso ist es libwayland … Als Abhängigkeit des Fenstermanagers sehe ich das allerdings nicht. Jedenfalls funktioniert die Erweiterung über ~/.config/xkb nicht, weswegen mir da wenig übrigbleibt, als in /usr/share/X11/xkb rumzubasteln.

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.

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.

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.

> 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. Hm, `libxkbcommon` ist wohl installiert, aber genauso ist es `libwayland` … Als Abhängigkeit des Fenstermanagers sehe ich das allerdings nicht. Jedenfalls funktioniert die Erweiterung über `~/.config/xkb` nicht, weswegen mir da wenig übrigbleibt, als in `/usr/share/X11/xkb` rumzubasteln. 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. > Ich würde dafür nicht das Tastaturlayout zerfrickeln, sondern das Scancode→Keycode-mapping dieser Tastatur anpassen. [Das hier](https://git.hrnz.li/Ulli/nixos/src/branch/main/profiles/keyboard/default.nix#L23) funktioniert für mich, siehe auch [Bogenlinux-Wiki-Artikel](https://wiki.archlinux.org/title/Map_scancodes_to_keycodes#Example_for_custom_hwdb). 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.
Owner

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!

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!
hrnz closed this pull request 2022-02-18 23:08:15 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
MkDocs
No Milestone
No Assignees
4 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/dokumentation#40
No description provided.