openbox › loggn.de

Sers, ich hatte ein kleines – stranges – Problem mit dem deutschen Tastaturlayout für die schnurlose Logitech K340 Tastatur (Unifying-Empfänger). Scheinbar erkennt Xorg die Tastatur nicht als normales Keyboard, somit zieht die Einstellung (XkbLayout) unter /etc/X11/xorg.conf.d/10-evdev.conf nicht!

Section "InputClass"
        Identifier "evdev keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
        Option "XkbLayout" "de"
EndSection

Section "InputClass"

Identifier "evdev keyboard catchall"

MatchIsKeyboard "on"

MatchDevicePath "/dev/input/event*"

Driver "evdev"

Option "XkbLayout" "de"

EndSection

Oder auch nach deutschem Arch Linux Wiki /etc/X11/xorg.conf.d/20-keyboard.conf.

Section "InputClass"
        Identifier "keyboard"
        MatchIsKeyboard "yes"
        Option "XkbLayout" "de"
        Option "XkbVariant" "nodeadkeys"
EndSection

Section "InputClass"

Identifier "keyboard"

MatchIsKeyboard "yes"

Option "XkbLayout" "de"

Option "XkbVariant" "nodeadkeys"

EndSection

In der Desktopumgebung, in meinem Fall Openbox, hatte ich dennoch das englische Tastaturlayout. Spaßeshalber habe ich dann eine kabelgebundene Tastatur angeschlossen, schwub-die-wub hatte ich das deutsche Tastaturlayout. *strange*

Der Befehl …

setxkbmap de

1	setxkbmap de

… stellt mir dann dennoch das deutsche Tastaturlayout für die K340 im X-Server ein. Damit der Befehl automatisch beim Starten ausgeführt wird, habe ich ihn in die Openbox Autostart-Datei (/home/USER/.config/openbox/autostart oder /etc/xdg/openbox/autostart) geschrieben.

Eigentlich ist das Problem so banal, dass sich der Artikel dafür gar nicht lohnt, aber ich wollte es dokumentiert wissen. 🙄

In den letzten Tagen habe ich mich mal wieder mit Arch Linux und dem Fenstermanager Openbox auseinander gesetzt. Viele werden Arch Linux, genauso wie ich, ohne Login-Manger benutzen – d.h. man loggt sich auf der ersten virtuellen Konsole (tty1) ein und startet dann mit dem Befehl startx den X-Server – sollte er nicht schon von alleine über die .bashrc starten.

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ] ; then
startx
fi

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ] ; then

startx

In den meisten Fällen wird nun über die .xinitrc der Fenstermanager, in meinem Fall Openbox, gestartet.

# start ConsoleKit, DBUS and OpenBox
exec ck-launch-session dbus-launch --sh-syntax --exit-with-session openbox-session

1 2	# start ConsoleKit, DBUS and OpenBox exec ck-launch-session dbus-launch --sh-syntax --exit-with-session openbox-session

Jetzt habe ich immer, wenn ich mal nicht am Platz war, ein Meeting hatte oder eine Raucherpause eingelegt habe, meinen Bildschirm über den XScreenSaver gesperrt. Irgendwann hatte sich der Bildschirmschoner aufgehangen und ich musste ihn über eine virtuelle Konsole (STRG+ALT+[F1-F6]) beenden. Währenddessen kam mir in den Sinn, dass einfach jemand trotz gesperrten Bildschirms auf das tty1 (erste virtuelle Konsole) wechseln und den X-Server mit STRG-C beenden kann, um dann als User die Linux-Kiste unsicher zu machen – das geht mal garnicht!

UPDATE_2012-05-23: Sollte ihr den X-Server über die /etc/inittab (Runlevel 5) starten, …

x:5:once:/bin/su USERNAME -l -c "/bin/bash -login -c startx"

1	x:5:once:/bin/su USERNAME -l -c "/bin/bash -login -c startx"

… muss die virtuelle Konsole nicht über vlock abgesichert werden – weil kein Login auf dem TTY stattfindet. /UPDATE_ENDE

Also habe ich mich nach einer Lösung umgeschaut Linux – Sicherheit – startx – CTRL+C, CTRL+ALT+BACKSPACE und SysRQ weiterlesen

Schlagwort: openbox

Arch Linux – Xorg – deutsches Tastaturlayout – Logitech K340 Tastatur schnurlos

Linux – Sicherheit – startx – CTRL+C, CTRL+ALT+BACKSPACE und SysRQ