Re: [Neo] remap für Linux: Problem mit der Interpretation der Mod-Werte.
Am 02.04.2011, 22:53 Uhr, schrieb Navid Zamani navid.zam...@googlemail.com: Xmodmap ist im Prinzip veraltet. Es wurde schon mit X11R6.1 (1996) durch die X Keyboard Extension (xkb) ersetzt, die sehr viel flexibler ist. Ja, OK, aber da scheint es kein Werkzeug wie xmodmap zu geben, was die Änderung einzelner Tastenbelegungen erlaubt. Sieht alles seeehr „overengineered“ aus… Habs mir grad noch genauer angeschaut. Grausig. […] 4) Du könntest die xkb-Dateien in /usr/share/X11/xkb/ ändern. Brauchst dazu aber Administratorrechte, und für einfache Umbelegungen sollte man auch nicht mit diesen Dateien rumspielen. Genau. Dafür, denke ich mir jetzt, muss es doch sowas wie eine „$HOME/.xkb“ geben. Hmm. Bei openSUSE war mir mal im Init-Skript /etc/X11/xinit/xinitrc.common aufgefallen, dass man wie die $HOME/.Xmodmap auch eine $HOME/.Xkbmap speichern kann, die dann automatisch bei Systemstart eingelesen wird. Aber da ergeben sich wahrscheinlich die gleichen Probleme wie bei Punkt 3): xkbcomp (das von setxkbmap aufgerufen wird) verursacht irgendwelche Fehler mit Abstürzen. Weiß nicht, ob das auch bei anderen Distributionen so ist (bei Ubuntu hab ich da nix entdeckt). Ich schätze so wie das Script jetzt ist, reicht es dann erstmal. Es tut was es soll, und die paar Ausnahmen kann ich dann auch manuell machen, falls sie auftreten. (Bugs gibts jetzt eigentlich nur, wenn ein Zeichen auf der gleichen Taste doppelt belegt ist, oder die Taste vorher garnicht belegt war. Was ja bei NEO eher nicht vorkommt. :) Jo, denke ich auch. Hab mir dein Skript mal kurz angeschaut, das sollte eigentlich gehen. Klar, für die besagten Fälle gibt es erstmal keine Lösung. Ich wollte eigentlich auch mal was umfangreicheres dazu machen, ein Programm, dass (ähnlich wie MSKLC für Windows, nur eben komplexer) eine Tastaturbelegung bequem per grafischer Oberfläche erzeugen kann und dann alle möglichen Treiber daraus erzeugt. Ist aber nichts in Sicht, dass ich mal damit anfangen werde, denn ich hänge ja noch bei den blöden xkbcomp-Bugs rum. Und meiner Meinung hätte eine Consulting-Firma xkb nicht besser zu einem Kandidaten für thedailywtf.com machen können. Ganz Virtudyne und Paula Brillant verneigen sich. ;)) Naja, schön an xkb ist, dass es so flexibel ist. Man kann eben Sachen machen, für die man unter Windows komplizierte Drittprogramme bemühen muss. Es hat nur eben einen Grund, dass unter Windows Tastaturbelegungen mit der Komplexität von Neo nicht von Haus aus machbar sind: Kaum einer nutzt sie, Neo ist überhaupt eine der ersten Belegungen mit mehr als vier Ebenen (spontan fällt mir da nur noch die Kanadisch-Multilinguale ein, mit 5 Ebenen). Unter Linux macht sich das dann so bemerkbar, dass diese erweiterten Funktionen von xkb (256 Ebenen, Overlays, Tastenaktionen unabhängig von Keysyms...) zwar auf dem Papier und im Protokoll existieren, aber voller Bugs und Fehler stecken, weil niemand das je testen musste. Die Treiberschreiber in der Liste hier können ein Lied davon singen. Ganz zu schweigen davon, dass z.B. Qt viele der Fähigkeiten von Xkb auch nicht unterstützt (oder nicht korrekt handhabt). Weswegen Neo-Leute Probleme mit KDE-Programmen haben, was Tastenkombinationen und die 4. Ebene angeht. Xkb ist eigentlich gar nicht s schlecht. Eine Xmodmap ist einfach zu unflexibel für viele Zwecke. Die unschönen Sachen kommen eigentlich alle entweder wegen Kompatibilitätsüberlegungen oder Bugs zu Stande. Ein bisschen Overengineering ist vielleicht schon dabei, OK. ;-) Schade auch, dass es kaum jemanden gibt, der sich mit xkb auskennt, und noch weniger, die bei X.org daran arbeiten (anscheinend nur einer). Schon seit Jahren steht xkb2 auf der Wunschliste, aber ob das jemals kommt, steht in den Sternen. Das sollte auch vieles vereinfachen und entrümpeln, und einige Beschränkungen (256 Keycodes, 4 Gruppen) beseitigen. Soviel mal zur Ehrenrettung. Geniess die Sonne! Tu ich. Peter
Re: [Neo] remap für Linux: Problem mit der Interpretation der Mod-Werte.
Am 03.04.2011 16:31, schrieb Peter Eberhard: Hmm. Bei openSUSE war mir mal im Init-Skript /etc/X11/xinit/xinitrc.common aufgefallen, dass man wie die $HOME/.Xmodmap auch eine $HOME/.Xkbmap speichern kann, die dann automatisch bei Systemstart eingelesen wird. Aber da ergeben sich wahrscheinlich die gleichen Probleme wie bei Punkt 3): xkbcomp (das von setxkbmap aufgerufen wird) verursacht irgendwelche Fehler mit Abstürzen. Naja, is ja auch nicht mehr als ein Shell-Script das die dann mit xkbcomp läd. Ich wollte eigentlich auch mal was umfangreicheres dazu machen, ein Programm, dass (ähnlich wie MSKLC für Windows, nur eben komplexer) eine Tastaturbelegung bequem per grafischer Oberfläche erzeugen kann und dann alle möglichen Treiber daraus erzeugt. Ist aber nichts in Sicht, dass ich mal damit anfangen werde, denn ich hänge ja noch bei den blöden xkbcomp-Bugs rum. Nur bitte bitte, ich hab da eine ganz große Bitte: Heutzutage wird immer so getan, als ob GUIs unbedingt „bequem“er wären. Leider verwechseln die meisten dabei „effizient” mit „einfach”, und es kommt was raus, was wieder weniger effizient ist. Z.B. werden da Tastenkombos komplett weggelassen, und alles ist nur noch mit der Maus steuerbar. Und automatisieren kann man schon gleich garnix mehr. Der Computer verkommt von einer Maschine mit der man seine Arbeit automatisieren kann zu einem festverdrahteten Haushaltsgerät. Und als Argument hört man immer, dass ja alle es bedienen können sollen. Dabei bewirkt es auch, dass intelligentere Leute es nicht mehr bedienen können, oder ewig brauchen. OS X ist da ein Paradabeispiel, da ich da jedes mal komplett stecken bleibe… bis ich mir denke „Hmm, wie würde ein absolut unfähiger DAU an die Sache rangehen?“ *Und dann klappts!!* ;) Das ist jetzt nicht böse dahergeredet, denn eigentlich will ich OS X mögen. Aber die Erfahrung zerstört dann meine Hoffnungen immer. :/ Solltest du was für Linux proggen, kann ich dir nur empfehlen, die beiden UNIX-Grundregeln zu benutzen: A) Alles ist eine Datei. (Hier sündigen KDE und Gnome schon gewaltig.), und B) Ein Programm kann eine Sache. Und die richtig. :) Dann kann es natürlich immer noch eine GUI haben, aber es bleibt kompatibel und automatisierbar. Ein Idealbeispiel ist meiner Meinung nach Maya. Dort ist alles was man macht ein Scriptbefehl, und die UI und der Rest sind sauber getrennt. Das geht so weit, dass man ein paar Sachen machen, dann die Kommandozeile aufklappen (Quake-Style), die nun dort stehenden Scriptbefehle markieren, und sie den „Shelf” ziehen kann. Fertig ist ein Knopf mit einem neuen Werkzeug dahinter. :) So, das war nur was Inspiration. :) Naja, schön an xkb ist, dass es so flexibel ist. Man kann eben Sachen machen, für die man unter Windows komplizierte Drittprogramme bemühen muss. Aber dann hätte man auch gleich einfach Tastenlayouts als C-Bibliothek einlesen und ausführen können. ;) (Auch gerne interpretiert oder JIT-Kompiliert.) Ok, es ist schwer, zu sagen was ich genau meine. Aber gottseidank hat das jetzt einen Namen: Inner-platform anti-pattern: http://en.wikipedia.org/wiki/Inner-platform_effect :D „the tendency of software architects to create a system so customizable as to become a [...] poor replica, of the software development platform they are using.“ Das ist wie TypoScript. Eine Script-Sprache für Web-Vorlagen… geschrieben in einer Script-Sprache für… Web-Vorlagen (PHP). Die zwar genau so kompliziert ist wie PHP (wenn nicht sogar noch mehr, da man sich erst noch zusätzlich da reinlesen muss), aber trotzdem vieles nicht kann. Wozu soll man sie dann *überhaupt* benutzen? ;) Unter Linux macht sich das dann so bemerkbar, dass diese erweiterten Funktionen von xkb (256 Ebenen, Overlays, Tastenaktionen unabhängig von Keysyms...) zwar auf dem Papier und im Protokoll existieren, aber voller Bugs und Fehler stecken, weil niemand das je testen musste. Ist aber auch ein ganz typisches Symptom des „inner-platform effect“s. Eine Xmodmap ist einfach zu unflexibel für viele Zwecke. Da geb ich dir ja auch recht. :) Ich bin halt jemand, der auf die drei Es steht: Emergenz, Effizienz und Eleganz. Die Leistungsfähigkeit von xkb lässt sich garantiert auch mit weniger Komplexität erreichen. Also weniger Regeln (Emergenz), die dafür leistungsfähiger sind (Effizienz), da sie allgemeinere Konzepte verwenden (Eleganz). Schade auch, dass es kaum jemanden gibt, der sich mit xkb auskennt, und noch weniger, die bei X.org daran arbeiten (anscheinend nur einer). Und noch ein Symptom, das für den „inner-platform effect“ typisch ist. Im Ernst, das liest man jedes Mal bei den Geschichten darüber. :) Schon seit Jahren steht xkb2 auf der Wunschliste, aber ob das jemals kommt, steht in den Sternen. Das sollte auch vieles vereinfachen und entrümpeln, und einige Beschränkungen (256 Keycodes, 4 Gruppen) beseitigen. Soviel mal zur Ehrenrettung. Na da bin ich mal gespannt. Ich hoffe es reisst ganz X
Re: [Neo] remap für Linux: Problem mit der Interpretation der Mod-Werte.
Am 01.04.2011 03:32, schrieb Peter Eberhard: Was dich so verwirrt, ist die (mMn schlecht gewählte) Bezeichnung der Neo-Shift-Tasten Mod3 und Mod4. Die sind nämlich etwas völlig anderes als die Mod1-5 des X window systems. Neo-Mod4 ist, in die Sprache der Neo-Xkbmap übersetzt, tatsächlich ISO_Level5_Shift, und das wird vom Neo-xkb-Treiber auf X-Mod3 gelegt (weil Mod4 schon für die Super-Tasten vorgesehen ist). Das ganze ist aber noch weit komplizierter: Heilige Scheisse! ;) Xmodmap ist im Prinzip veraltet. Es wurde schon mit X11R6.1 (1996) durch die X Keyboard Extension (xkb) ersetzt, die sehr viel flexibler ist. Ja, OK, aber da scheint es kein Werkzeug wie xmodmap zu geben, was die Änderung einzelner Tastenbelegungen erlaubt. Sieht alles seeehr „overengineered“ aus… Habs mir grad noch genauer angeschaut. Grausig. Xkb stellt aus Kompatibilitätsgründen, aber auch der Praxis wegen (wenn man einzelne Tasten ummappen möchte, so wie du) auch noch die Xmodmap zur Verfügung. Ok, also doch xmodmap. ;) Im von dir angeführten Beispiel: keycode 40 = a A d D braceleft Greek_alpha Down Down U2200 NoSymbol eth ETH a und A sind Neo (Gruppe 1, Levels 1 und 2) d und D sind Qwertz (Gruppe 2, Levels 1 und 2) Greek_alpha bis NoSymbol [leer] sind Neo, Levels 3-8 (Gruppe 1) eth und ETH sind Qwertz (Gruppe 2), so wie es von Linux um zusätzliche Zeichen erweitert wird (ð auf AltGr+d). Ja OK, nur wird ein Script das die hartcodet natürlich nicht viel Sinn machen, da es nur bei mir und nur bei dem exakten Setup funktioniert. :) Die komplette aktuelle xkbmap kannst du dir genauer anschauen, indem du xkbcomp :0 neo.xkb Ja, das war es, was ich sah, als ich vorhin „Grausig“ sagte. ;) Eine einfache Zuordnung 0xa0 → Spalte 9 (die bei dir bei Taste 40 zutrifft) ist also nicht möglich. Ich würd mir da mal nicht so sicher sein, weil… ;) 2) Wenn du bei der Neo-xkbmap bleiben willst, kannst du einfach annehmen, Neo wäre die erste Gruppe, und die entsprechende Spalten-Zuordnung vornehmen (Ebene 1+2 = Spalte 1+2, Ebene 3-6 = Spalten 5,7,6,9). Dann solltest du aber darauf hinweisen. Das kann man ja schön in eine halbautomatisch generierte Konfigurationsdatei auslagern. Dann läufts auch überall, bis der Nutzer das Setup ändert. :) 3) Du könntest nicht die xmodmap, sondern die xkbmap ändern, die du wie oben per xkbcomp erzeugst. […] Leider funktioniert das oft nicht, xkbcomp ist ziemlich verbugt. Bei mir jedenfalls. […] Bei mir stürzt bei sowas gerne mal der X-Server ab – aber auch nicht immer und nicht nachvollziehbar, ich bin noch nicht dahintergekommen, warum. Also ich hab hier grad das Update von XOrg 1.9.5 auf 1.10.0.901 vor, da der nVidia-Treiber das endlich unterstützt. Ich hab keine Lust auf Stabilitätsprobleme. Bin froh dass die zusammen mit der ATi-Karte jetzt nicht mehr in meinem System existieren. ^^ 4) Du könntest die xkb-Dateien in /usr/share/X11/xkb/ ändern. Brauchst dazu aber Administratorrechte, und für einfache Umbelegungen sollte man auch nicht mit diesen Dateien rumspielen. Genau. Dafür, denke ich mir jetzt, muss es doch sowas wie eine „$HOME/.xkb“ geben. 5) Du könntest ein echtes C-Programm Iiiih, nee, Haskell oder garnicht. ;) schreiben, das auf Xkb-Routinen zurückgreift, um die Zuordnung Modifier → Spalte zu finden. Die Einzelheiten findest du in www.x.org/docs/XKB/XKBproto.pdf, übrigens Pflichtlektüre, wenn du xkb wirklich tief verstehen willst. Nee, will ich wirklich ganz wirklich auf garkeinen Fall. ^^ Ich will mich damit nur so wenig wie irgend möglich befassen, da ich nebenher noch die ganze Unreal-Engine, halb Haskell, Tonnen an APIs (und wenn ich Bock hab noch Quantenphysik ;)) lernen muss. Und dabei ist die *eigentliche* Arbeit garnicht mitgerechnet. Ich schätze so wie das Script jetzt ist, reicht es dann erstmal. Es tut was es soll, und die paar Ausnahmen kann ich dann auch manuell machen, falls sie auftreten. (Bugs gibts jetzt eigentlich nur, wenn ein Zeichen auf der gleichen Taste doppelt belegt ist, oder die Taste vorher garnicht belegt war. Was ja bei NEO eher nicht vorkommt. :) So sieht es aus. Meiner bescheidenen Meinung nach. Und meiner Meinung hätte eine Consulting-Firma xkb nicht besser zu einem Kandidaten für thedailywtf.com machen können. Ganz Virtudyne und Paula Brillant verneigen sich. ;)) Trotzdem erstmal vielen vielen dank für die Hilfe, Peter. :) Geniess die Sonne! Navid
[Neo] remap für Linux: Problem mit der Interpretation der Mod-Werte.
Hallo, wie ihr euch vielleicht erinnert, wollte ich ein Tasten-Zuordnungsscipt schreiben. Nun, ich bin fast fertig. Aber es gibt ein Problem: xev spuckt mir die Mod-Tasten-Zustände so aus: 0x80 → Mod3 0x20 → Mod4 …und folglich… 0xa0 → Mod3+Mod4 Das Problem ist nun, dass bei xmodmap die Mappings z.B. für „A“ (QWERTZ „D“) so aussehen: keycode 40 = a A d D braceleft Greek_alpha Down Down U2200 NoSymbol eth ETH (Ich hab QWERTZ auch noch als Zweitlayout, wie man sehen kann.) Also muss ich aus z.b. 0xa0 finden, welche „Spalte“ in der „keycode 40“-Zeile ich ersetze… Das scheint mir jetzt irgendwie kaum zu machen… (Ausser man könnte rausfinden, welche Spalte welchem Mod-Zustand zugeordnet wäre. Und 0x80=Mod3 passt da irgendwie garnicht ins Konzept, da es laut „xmodmap -pm“ 0x20=Mod3 sein müsste… [Ja, hab extra nochmal nachgeschaut ob ich nix verwechselt hab.] Oder ist ISO_Level5_Shift mod4, obwohl daneben mod3 steht??) Aaaber: NEO hat doch so schöne xmodmap- und andere Generierscripte. Daher meine Frage: Wo fände ich in den Scripten ein Codeschnipsel, das mir hierbei behilflich wäre? Erinnert sich jemand an was, das mir das möglich machen würde? Navid