Hallo, Am Wed, 16 Mar 2022, Michael Behrens schrieb:

Eventuell das ibus-Problem hier:

https://www.opensuse-forum.de/thread/64868-tastatur-layout-stellt-sich-nach-...

Das hatte ich auch nach dem Upgrade, deshalb ist es mir gerade wieder eingefallen.

Am 16.03.22 um 13:17 schrieb Norbert Zawodsky:

...

Tastatur-Layout jedes mal hartnäckig auf en_us gestellt

Ansonsten: was ist die Ausgabe von $ locale und $ locale -a als User und als root? Da gibt's immer (noch) wieder Fehlerquellen, daß die ein oder andere Form der Angabe der locale nicht gefressen wird... Ich erinnere nur an z.B. de_DE de_DE.utf8 de_DE.utf-8 de_DE.UTF-8 de_DE@euro de_DE.iso885915 de_DE.iso8859-15 de_DE.iso-8859-15 de_DE.ISO-885915 de_DE.ISO-8859-15 (und daß bei en_US das hinter dem . auch nur teilweise tut/tat). (und wobei Groß-/Kleinschreibung eigentlich irrelevant sein sollte) Inzwischen scheint man sich zumindest bei den ISO-Varianten auf die 'iso8859xx' und bei UTF-8 auf die 'utf8' Version geeinigt zu haben... Ansonsten: ich kenne das Phänomen von z.B. KDE, das generell nach dem Start seine (dämlichen) Einstellungen der Tastatur ungefragt und bedingungslos reinknallt. Da ist dann in meinem Fall ein beherztes 'xmodmap ~/.Xmodmap' per 'Autostart' fällig. Halt was dein Desktop/Windowmanager anbietet. Die ~/.xession ist jedenfalls zu früh. Nicht daß ich KDE als Desktop verwenden würde[1]. Analog läuft das AFAI[KR] auch bei XFCE und anderen Desktops (Gnome z.B. hab ich _ewig_ nicht mehr auch nur testhalber mal gestartet[2]), bei XFCE bin ich mir aber recht sicher: wenn ich da unter WMaker in dessen Tastatur-Config gehe und was ändere drückt mir das die Einstellungen auch in das laufende X11 rein. Da hilft dann je nach Verkorkstheit ein beherztes 'setxkbmap us; xmodmap ~/.Xmodmap' (mein eigenes Tastaturlayout basiert auf dem en_US layout, schon wg. []{}\/ usw.[3] -dnh [1] hab ich seit KDE 1.1.2 nicht mehr *hrhrhr* WindowMaker ist a) viel schlanker (war's schon damals: ~2MB vs. IIRC >>100MB [4]) und b) schöner und effizienter zu bedienen. Aber diverse KDE Software verwende(te) ich dann doch gern mal, und sei's nur kshisen ;) Testhalber gestartet hab ich's aber auch viel später noch immer wieder mal (bis 4.irgendwas). [2] seit 1.2 oder so vermutlich, seit dem das systemd erfordert ist das aber eh raus, dat kommt auch nimmer rein ;) [3] nicht ganz aktuell, da aber eh nur als Anregung bzw. Vorlage gedacht ist das egal: http://dhaller.de/linux/Xmodmap http://dhaller.de/linux/Xmodmap.pdf Entscheidend ist die Grundreihe (plus die Belegung von Caps) mit Esc Return Shift Shift Strg "AltGr" Alt Space Alt "AltGr" "Meta/aka_Esc" Strg "AltGr" == Mode_switch == ISO_Level3_Shift -> Dritt-/Viertbelegung der Tasten. sowie ESC auf der Caps_Lock-Taste. Denn so kann man die 3./4. Belegung bequem mit beiden Händen (meist per Daumen, aber nicht immer ;) aktivieren. Ich tippe damit auch und gerade Deutsch samt Umlauten so schnell wie auf ner deutschen Belegung. Eher schneller. Und \/[]{} usw. sind _vieeel_ einfacher einzugeben. Aber eigentlich ist alles, außer der Grundidee mit der Grundreihe vor allem Geschmachssache. Einen großen Nachteil hat die Aktion allerdings: du wirst jede Standardbelegung (us, besonders aber die de) jedesmal ausgiebig verfluchen, wenn du deine eigene nicht verwenden kannst! Da meine zumindest das US-Basislayout kaum ändert geht's noch, aber bei ner de-Belegung fluch ich permanent ob derer Idiotie, obwohl ich auch die "kann". Daß du dennoch permanent ungewollt Caps anschaltest wird dennoch vorkommen ;) *ARGH* ich seh grad, im PDF fehlt die 105te Taste! Naja, nicht so schlimm, die fristet hier eh nur ein ungenutztes pseudo-Dasein als Hyper_L ... Da muß ich mir mal was besseres einfallen lassen -- oder Hyper mehr verwenden ;) Bei eigenen Experimenten hilft es 1. erstmal die aktuelle Belegung zu speichern: xmodmap -pke > ~/.Xmodmap.default 2. ein xterm vorzubereiten, das nur noch auf ein Return wartet vorzubereiten, durch Eingabe (ohne Return) von: setxkbmap de; xmodmap ~/.Xmodmap.default 3. fleissig xkeycaps und xev zu verwenden ;) Und jep, das alles klappt noch wunderbar auch mit weitgehend aktuellem Softwarestack, konkret Xorg 21.1.3, Mesa 21.3 und Gedöns usw. Nur die glibc ist "aus Gründen[tm] (des chrooten könnens)" etwas angestaubt. Wie's mit Wayland (+Gnome z.B.) ausschaut hab ich keine Ahnung was z.B. setxkbmap/xmodmap angeht bzw. was es stattdessen gibt. HTH und "Have a lot of fun!" [4] inzwischen ist (nun unter 64bit und mit deutlich neuerem und 64bit Kernel/Code) auch WMaker fetter geworden, aber dennoch ;0 Ich verwende allerdings auch recht fette Bitmaps als Bildschirmhintergründe die zumindest z.T. auch bei wmaker beim RAM Platz brauchen (mehr als die reine Verwaltung, bei X11 landet aber IIRC mehr). $ for p in $(pidof wmaker); do grep '^VmRSS' /proc/"$p"/status ; done VmRSS: 5988 kB VmRSS: 556 kB Das ist nicht ganz alles, was es für wmaker braucht, aber das relevante. Naja, wenn man nen Firefox/Chrome oder ne Java-App startet ist es da eher solange egal ob man's unter WMaker mit den vielleicht 10M oder KDE mit 500M macht -- bis einem die entscheidenden z.B. 200MB RAM fehlen, wenn man was kompilieren will... Hab hier schon was nur kompiliert bekommen, indem ich das Kompilieren aufgeteilt habe in Assembler generieren, den dann zu Objektcode "compilen" und dann linken. Alles auf einmal ging mit meinen mageren 4GB bei allen Versuchen nicht (und dabei waren alle Speicherfresser aus und sogar diverse Systemdienste gestoppt)... Dämlich programmiert? Definitiv. Hach, ich hab mit damals großzügigen 4MB(!) RAM angefangen und IIRC bald auf 8MB aufgerüstet, und nur etwa 25 Jahre später sind 4GB nicht mehr genug... O tempora, o mores ;) Wobei: einklich geht das ja noch, im Vergleich zu anderen Steigerungsraten bei der HW ... Was aber definitiv nervt ist die grassierende Gedankenlosigkeit diesbezüglich. Siehe beliebige Webseiten mit Tonnen von JS die massiv RAM und CPU brauchen. Und wozu? Für Schnickschnack, der schon 1995 einfach nur Scheiße war, Zeugs, das nix bringt, nur nervt. Ich sach nur <marquee>! *Bling Bling* das obendrein auch noch Scheiße aussieht oder DRM und das obendrein auch nur leicht angestaubte, aber noch per ESR supportete Browser ausschließt... Und ich hab jedenfalls genau gar keine Lust meine zugegebenermaßen über 10 Jahre alte Kiste aufzurüsten, nur weil z.B. Youtube mit JS sowohl den Firefox als auch Chrome minutenlang quasi lahm legt und wasweißich, 2 GB, RAM braucht um eine einfache verfickte Seite mit _einem_ verfickten Video anzuzeigen!!! (wenn's denn wenigstens p0rn wäre ;) Immerhin kann ich mit der selben CPU mit nur einem CPU-Thread(!) das verschissene Chromium oder den Firefox oder OpenOffice noch in weniger als 12 Stunden kompilieren! Einem ollen Athlon II X2 250 @ 3.0 GHz (as specced) von 2009 mit 4 GiB RAM DDR3-800 IIRC für den, der's genau wissen will. Aber das verschissene Youtube JS braucht ne Minute CPUtime auf beiden Kernen um eine einzige verfickte Videoseite anzuzeigen! GEHT'S NOCH???? Und schon das letzte Mal hab ich meine Kiste mehr oder weniger u.a. wegen beschissenem JS in beschissenen Webseiten aufgerüstet (von einem Athlon 500[5] mit $weißnimmer >= 768MB RAM :)) Und andere Seiten tun's gleich garnicht mehr in nem Firefox ESR 60/69 teils nichtmal 91 oder Chrome $nicht_ganz_aktuell aber noch zu $glibc kompatibel... Findet jemand z.B. die aktuellen Webseiten von beliebigen TV-Sendern (egal ob öR oder privat) auch nur ansatzweise [ ] gut bedienbar [ ] übersichtlich [ ] visuell ansprechend /me: *kotzimstrahl* bei _allen_ bzgl. aller Punkte plus der technischen Kritik! So, jetzt geht's mir ein bissl besser :) *tschulljung* *das mußte mal raus* [5] ja, _dem_ ersten und langsamsten Athlon _ever_, für "Slot A"! Und ich hab in den ~10 Jahren zweimal die Lüfter/Kühler Kombi anpassen müssen, weil mir die Plastikrahmen der Lüfter zerbröselt sind ... Lief mind. 2 Jahre mit per Klebeband[Tesa/ScotchTape/you-name-it] auf dem Kühlkörper gehaltenen Lüftern ;) PS: cboltz: wenn du das liest und antwortest: Du bist mein Held! :) -- Es ist heutzutage nicht einfach, eine komplette Desktop-Umgebung zu finden, die so schlank wie Emacs ist. -- Florian Diesch