Mal wieder: Deutsche Tastatur im DM

berni51

Open-Net-FreeBSD user
Hallo,

ich hab ein aktuelles DragonFly BSD installiert, lief auch alles glatt und das System ist OK - bis auf slim, den Display-Manager: Hier krieg ich einfach kein deutsches Tastaturlayout hin.

Hab eine einfache keyboard.conf unter /usr/local/etc/X11/xorg.conf.d erstellt mit folgendem Inhalt:


Code:
Section "InputClass"
    Identifier "Keyboard"
    MatchIsKeyboard "on"
    Option "XkbLayout" "de"
 EndSection


Unter FreeBSD klappt es damit immer, nicht jedoch unter DragonFly, der ignoriert das einfach. In der /var/log/Xorg.0.log
finde ich dann das hier:

Code:
[ 14347.343] (II) Using input driver 'kbd' for '<default keyboard>'
[ 14347.343] (**) Option "CoreKeyboard" "on"
[ 14347.343] (**) <default keyboard>: always reports core events
[ 14347.343] (**) <default keyboard>: always reports core events
[ 14347.343] (**) Option "Protocol" "standard"
[ 14347.343] (**) Option "XkbRules" "base"
[ 14347.343] (**) Option "XkbModel" "pc105"
[ 14347.343] (**) Option "XkbLayout" "us"
[ 14347.343] (II) XINPUT: Adding extended input device "<default keyboard>" (type: KEYBOARD, id 7)

Und jetzt find ich einfach nicht raus, wo diese Konfiguration zu finden ist.
 
Ja, danke. Habs rauf und runter gelesen, aber noch keine Lösung gefunden. Unter Xorg ist ja alles korrekt mit der Tastatur, nur slim, der DM, hat noch das us-Layout.
 
Da hast Du recht, da entwickelt keiner mehr. Aber es gibt nichts leichtgewichtigeres, und eigentlich auch nichts unproblematischeres. Er funktioniert einfach - nur diesmal nicht. Wobei ich das Problem eher bei DragonFly vermute.
 
Schau mal ins Handbuch unter Customizing X


Customizing X​

When an X session is started, shell scripts in the user's home directory can be used to start as many programs as desired. Most of the programs in these scripts should run in the background, but the last one (typically the window manager) should run in the foreground. When the window manager exits, the script will exit, and X will shut down or return to the xdm(1) login prompt.

The startx(1) command looks for a $HOME/.xinitrc script. If this script doesn't exist, the system's /usr/local/etc/X11/xinit/xinitrc file is used instead.

After the user logs in from xdm(1), the /usr/local/etc/X11/xdm/Xsession script checks whether there is a $HOME/.xsession script.

In the simplest case, your .xinitrc or .xsession script contains only one line specifying your preferred window manager:

cwm

Or you can get a little more fancy:

export LANG=en_US.UTF-8
setxkbmap -layout us,ru -option grp:sclk_toggle
xconsole -geometry -0+0 -fn 5x7 &
xclock -geometry 75x75-0-0 &
xsetroot -solid grey &
xterm -geometry 100x25-400+250 &
cwm

Note: make sure your .xsession file is executable.
 
Da hast Du recht, da entwickelt keiner mehr. Aber es gibt nichts leichtgewichtigeres, und eigentlich auch nichts unproblematischeres. Er funktioniert einfach - nur diesmal nicht. Wobei ich das Problem eher bei DragonFly vermute.
Ich vermute, dass es ein Konfigurationsproblem unabhängig von DragonFly ist, aber ich hab das noch nie genutzt. Als Alternative kannst du dir mal sddm ansehen. Da slim nicht mehr weiterentwickelt wird, halte ich es schon für möglich, dass der Grund bei slim zu suchen ist. xorg hat ja inzwischen eine abweichende Konfiguration (iirc gab es früher xorg.conf.d gar nicht).

Testen kannst du auch mal diesen Vorschlag (der meine Aussage mit der Konfiguration aber als Unsinn definiert): https://wiki.archlinux.org/title/SLiM#Change_Keyboard_Layout (dass du den Pfad anpassen musst, ist vermutlich klar)
 
Hab alle Tipps durch - nix hat sich geändert. Der slim ignoriert alles!
Klar könnte ich einen anderen DM nehmen: xdm, sddm, xenodm - die funktionieren ja alle. Aber der slim ist so herrlich einfach, eine conf-Datei, ein Hintergrundbild, eine keyboard.conf. und das war's - bisher jedenfalls. Hab ja noch einige slims hier laufen unter Free/Open/NetBSD und Devuan, und da klappt das mit der deutschen Tastatur. Nur dieses DragonFly zickt.
Aber ich bleibe dran und bin nach wie vor für jeden Hinweis dankbar.

Bedenkt aber, dass dieses Problem nur direkt im slim auftriit, danach unter Xorg stimmt die Tastatur.

LG
Berni
 
Bedenkt aber, dass dieses Problem nur direkt im slim auftriit, danach unter Xorg stimmt die Tastatur.

LG
Berni
Was mir gerade noch einfällt, da ich das gleiche Problem tatsächlich auch bei sddm hatte: Hat slim die Möglichkeit "Scripte" zu starten (zB vor dem Start)? Damit bei mir auch sddm deutsch ist, muss ich "setxkbmap de" starten lassen. Realisiert wird es über ein simples Script in /usr/local/share/sddm/scripts/Xsetup.
 
Laut slim.conf kann slim auch startup scripts ausführen - aber ein setxkbmap de führt er einfach nicht aus. Aber vielleicht muss ich wirklich ein script starten .....
 
Ich glaube bei OpenBSD ists zu 7.1 aus den Ports geflogen und als login-manager ist das ja auch Stück letztlich doch etwas sicherheitsrelevanter Software.

Ich fand SLIM auch cool, aber ich glaube der Zeitpunkt sich zu verabschieden ist schon sehr überfällig ;)
 
setxkbmap ist installiert und wird auch in der .xsession aufgerufen. Jetzt zusätzlich noch in der slim.conf (direkt und über ein Script, hab beides probiert). Der slim reagiert nicht die Bohne darauf.
Entweder haben die DragonFlyer den slim noch mehr beschränkt oder die machen die xorg Initialisierung so total anders, das der slim nicht mehr mitkommt.

In OpenBSD 7.0 war slim noch in den repos, bei 7.1 nicht mehr. Klar, das hat seinen Grund und vielleicht ist die Zeit wirklich reif für einen Wechsel. In OpenBSD bin ich ja schon auf den xenodm umgeschwenkt.
Aber vorher würde ich gern noch wissen, warum der slim sich so sperrt :cool:
 
Ich habe mir jetzt mal aus Spaß dragonfly unter bhyve installiert. Du bekommst slim ganz einfach umgestellt: Erstelle dir eine xorg.conf mit "Xorg -configure". die xorg.conf.new kopierst du nach /usr/local/etc/X11/xorg.conf (umbenennen nicht vergessen) und ergänzt die Section InputDevice beim Keyboard um
Option "XkbLayout" "de"

Danach service slim restart. Deutsch.
 
Nachtrag: Selbstverständlich funktioniert es auch ohne xorg.conf. Ich habe hierzu meine xorg.conf nach xorg.conf.d verschoben und den gesamten Inhalt gelöscht bis auf:

Code:
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbLayout" "de"

Die Ursache ist vermutlich einfach, denn der Unterschied zu deiner Konfiguration: InputDevice statt InputClass.

HTH
 
Tatsächlich, so funktionierts! Besten Dank @Columbo0815
Und im Nachhinein muss ich mich auch fragen, wieso ich da InputClass reingeschrieben hab. Vermutlich irgendwo mit C&P hergeholt. Mercie bien.
Jedenfalls kann der slim erstmal bleiben. :rolleyes:
 
Ich habe mir jetzt mal aus Spaß dragonfly unter bhyve installiert. Du bekommst slim ganz einfach umgestellt: Erstelle dir eine xorg.conf mit "Xorg -configure". die xorg.conf.new kopierst du nach /usr/local/etc/X11/xorg.conf (umbenennen nicht vergessen) und ergänzt die Section InputDevice beim Keyboard um
Option "XkbLayout" "de"

Danach service slim restart. Deutsch.
Warum heißt es eigentlich, dass dieses Procedere mit "Xorg -configure" out ist und dass man eigentlich überhaupt keine xorg.conf mehr verwenden sollte? An diesem Beispiel zeigt sich doch, dass altbewährte Methoden immernoch bestens funktionieren.
 
Weil man damit einen Prozess nutzt der so von den Entwicklern nicht mehr gedacht ist und schnell andere Probleme verursacht.
 
Aha. Aber nach wie vor generiert das Tool nvidia-xconfig eben direkt eine xorg.conf, mit der Nvidia-Karten im Zusammenhang mit dem nvidia-driver dann auch laufen und ohne diese xorg.conf eben nicht.
 
Aha. Aber nach wie vor generiert das Tool nvidia-xconfig eben direkt eine xorg.conf, mit der Nvidia-Karten im Zusammenhang mit dem nvidia-driver dann auch laufen und ohne diese xorg.conf eben nicht.
das sollte ja eigentlich nicht der Fall sein, außer du hast mehrere Karten und musst dann einen Treiber genau zuweisen.
Die automatisch erzeugten xorg.conf Dateien sollten auch nur ein Anhaltspunkt/Vergleich sein, damit man eigene Konfiguration ableiten kann.
Ob die dann in die vielen kleinen Dateien von heute oder in einer "großen" xorg.conf eingetragen werden oder auf beide verteilt, sehe ich auch nicht als wichtig an. Mir gefällt grundsätzlich die große xorg.conf schon besser, aber die kleinen dateien sind zB handlicher, wenn man sie auf ein neues System übernehmen will. Man kann dann besser auswählen, was davon man mitnehmen möchte ohne noch editieren zu müssen.

Besonders mit dem Automatismus von Nvidia habe ich auch schon Schiffbruch erlitten. Den würde ich deshalb nicht einfach so blind übernehmen.
 
Unter OpenBSD und Linux hab ich seit ... puh 10? ... Jahren gar keine Xorg.Confs mehr angelegt.
Ich glaube, das ist nicht ganz der Punkt. Wenn man einen AMD oder Intel Chip verwendet, braucht man unter FreeBSD auch keine xorg.conf. Bei einem Nvidia Chip scheint es aber im Zusammenhang mit dem propietären Treiber und nvidia-xconfig immernoch die einfachste Lösung zu sein. Und warum nicht? Mir wäre es natürlich auch lieber, mit einem "pkg install nvidia-driver" und dem entsprechenden Eintrag in der /etc/rc.conf wäre es getan. Unter Linux (hier natürlich auch wieder je nachdem, welches Linux), soll es manchmal nicht so einfach sein, die propietären Treiber von Nvidia zu installieren. Ob dann dabei auch eine xorg.conf dazugehört, weiß ich natürlich nicht.
Jedenfalls auch erfreulich, das Xorg -configure und xorg.conf hier zur Lösung eines Problems mit slim beigetragen haben.
 
Zurück
Oben