[Arch Linux] xkeyboard woes...

21/12/2008 - 12:56 von Sieghard Schicktanz | Report spam
Hallo,

hat eigentlich niemand außer mir Tastatur-Treiberprobleme mit dem aktuellen
Xorg?

Ich hab' hier ein "nicht mehr ganz neues" System mit einem Athlon XP 2400+,
einer ATI Radeon 9200 SE (rev 01), deutsche Tastatur und einer PS/2- und
parallel dazu einer USB-Maus (bzw. Trackball).

Xorg-Versionen:
xorg-server 1.5.3-4, xf86-input-keyboard 1.3.1-1, xf86-input-mouse 1.3.0-1,
xorg-xdm 1.1.8-1 (xorg 11R7.0-1).

Angefangen hat's damit, daß der Server erstmal unbedingt auf der
Verwendung des xkbcomp bestanden hat, den aber mit völlig ungeeigneten
Daten versorgt hat, trotz korrekten Angaben bei den _neuen_ Optionen zur
Definition des Layouts. Das konnte ich mit einer Krücke, die den Keyboard-
Compiler direkt versorgte, erstmal umgehen.
Mit der nàchsten "Lieferung" kam dann ein Server, der die neuen Optionen
einigermaßen richtig auswertete, so daß der xkbcomp nur noch màßig
protestiert, aber ein funktionierendes Layout produziert.
"Netterweise" hàngte sich dann aber der Treiber gerne komplett auf,
besonders beim Rückschalten aus einer Sitzung in den xdm - keine neue
Sitzung, kein Umschalten auf Textmode, nichtmal mehr ein Reboot oder Halt
per Tastatur möglich. (Da ist es doch recht nützlich, wenn man den "Magic
Sysrequest" im Kernel aktiviert hat;)
Ursache scheint die neue Automatik zu sein, die die Tastatur (und Maus) per
HAL zu erkennen versucht, was bei einer nicht-US-stàmmigen Tastatur aber
zumindest zum Teil klàglich scheitern _muß_ - woher kann der HAL wissen,
was für ein landesspezifisches Layout da zu benutzen ist?
Dummerweise _ignoriert_ diese Funktion aber die Angaben in der xorg-conf -
Sektion für die Tastatur und stellt immer US-Layout ein.
Deswegen muß man als "Fremdsprachler" (simmer schon soweit!) diese
Erkennung wieder abschalten. Geht ja wenigstens, auch wenn dann der Server
wieder mosert ((EE) config/hal: NewInputDeviceRequest failed): In der
"ServerFlags"-Sektion müssen da die _beiden_ Eintràge

Option "AllowEmptyInput" "off"
Option "AutoAddDevices" "off"

'rein. Sinnvollerweise _muß_ "AllowEmptyInput" auf "off" geschaltet werden,
sonst wird nàmlich, im Widerspruch zum Options-Namen, laut man-page-
Beschreibung, _gar_ _kein_ Tastatur- und Maus-Treiber geladen! Meldungen:

(WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be
disabled.
(WW) Disabling Mouse0
(WW) Disabling Keyboard0

Was soll denn _der_ Unsinn?
Wenn das wenigstens "DisableInputDevices" hieße oder so, dann wàr' das ja
verstàndlich - aber _so_? Wer hat das bloß verbrochen...
Naja, _einfacher_ ist die Konfiguration damit jedenfalls nicht geworden,
meine funktionierende Tastatur-Einstellung sieht jetzt "einfach" so aus:

Section "ServerFlags"
...
Option "AllowEmptyInput" "off"
Option "AutoAddDevices" "off"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbLayout" "de"
Option "XkbVariant" "nodeadkeys"
Option "XkbKeycodes" "xfree86(xfree86)+aliases(qwertz)"
Option "XkbTypes" "complete"
Option "XkbCompat" "complete"
Option "XkbSymbols" "pc(pc105)+de"
Option "XkbGeometry" "pc(pc105)"
EndSection
(leicht gekürzt.)
Ob da noch was weggelassen werden kann, hab' ich jetzt
vorsichtigkeitshalber erstmal nicht weiter untersucht...

Nachtrag: könnte es sein, da der "evdev"-Treiber den Unsinn produziert?
Der soll ja wohl eine Art Unversal-Treiber für alles eingabemàßiges sein,
das so in einem System auftauchen kann. Evtl. noch bisserl roh?

Bleibt erstmal nur noch das Problem, daß sich der xdm / X-Server gerne mal
verklemmt und z.B. den Login-Bildschirm nur teilweise anzeigt. Dann ist
grundsàtzlich die Tastatur total tot, nichtmal die Num-Lock-LED reagiert
noch. Anscheinend karrert der dann quer durch's System und verbiegt alles
mögliche, weil dann sogar nach einem Reboot z.T. recht "interessante" Sachen
passieren - da wird dann schonmal das CD-Laufwerk nicht mehr erkannt oder
seine Schublade geht auf, es fehlt plötzlich eine Platte oder hat keine
Partitionen mehr (kann einem einen ganz schönen Schreck verpassen...) und
àhnliches...
Jedenfalls alles recht eigenartige Sachen.
(Da möchte man doch gar eine Erweiterung für die Kernel-Funktion "Magic
Sysrequest Key" vorschlagen: eine Eingabe zum "Abschießen" des X-Servers
und bzw. zumindest zum Re-Initialisieren der Tastatur...)

Wundert mich wirklich, daß das nur mir so gehen sollte - trotz der nicht
mehr ganz aktuellen Grafikkarte, die sich dazu ganz im Gegensatz völlig
brav und unaffàllig verhàlt...

(Weitergabe von Adressdaten, Telefonnummern u.à. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder àhnlichem)
Mit freundlichen Grüßen, S. Schicktanz
 

Lesen sie die antworten

#1 Jens Hornung
21/12/2008 - 23:49 | Warnen spam
Sieghard Schicktanz wrote:

Ursache scheint die neue Automatik zu sein, die die Tastatur (und Maus)
per HAL zu erkennen versucht, was bei einer nicht-US-stàmmigen Tastatur
aber zumindest zum Teil klàglich scheitern _muß_ - woher kann der HAL
wissen, was für ein landesspezifisches Layout da zu benutzen ist?
Dummerweise _ignoriert_ diese Funktion aber die Angaben in der xorg-conf -
Sektion für die Tastatur und stellt immer US-Layout ein.



Hier [1] steht einiges, wo man einige Einstellungen aus der alten xorg.conf
bezüglich Tastaturlayout jetzt tàtigen kann. Ich habe dazu folgende Zeilen
geàndert:

/etc/hal/fdi/policy/10-keymap.fdi:

[...]
<merge key="input.xkb.layout" type="string">de</merge>
<merge key="input.xkb.variant" type="string">nodeadkeys</merge>
[...]

Ja, solche Updates können in Arch teilweise nette Überraschungen verursachen
;-) Falls du KDE 4 verwendest, solltest du dort den Tastaturtreiber auch auf
evdev umstellen.

Gruß, Jens

[1] http://wiki.archlinux.org/index.php...figuration

Ähnliche fragen