xorg7.4 - hal - xorg.conf

georg

Well-Known Member
ich habe mich nach dem xorg7.4 upgrade mit der Konfiguration, die zuvor in xorg.conf vorgenommen wurde und auch immer noch vorgenommen werden kann herumgeschlagen.

Verwendet man HAL können diese Konfigurationen in den Policy-Dateien von HAL vorgenommen werden. Dazu habe ich im Directory /usr/local/etc/hal/fdi/policy/ folgende Dateien angelegt:

100-x11-input.fdi
101-keyboard-input.fdi
102-mouse-input.fdi

Diese beinhalten:

Code:
# more 100-x11-input.fdi
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.x11_driver" type="string">kbd</merge>
    </match>
    <match key="info.capabilities" contains="input.mouse">
      <merge key="input.x11_driver" type="string">mouse</merge>
    </match>
  </device>
</deviceinfo>

und:
Code:
 [root@pinky /usr/local/etc/hal/fdi/policy]# more 101-keyboard-input.fdi
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.x11_driver"  type="string">kbd</merge>
      <merge key="input.xkb.Model"   type="string">pc105</merge>
      <merge key="input.xkb.Layout"  type="string">de,ara</merge>
      <merge key="input.xkb.Rules"   type="string">xorg</merge>
      <merge key="input.xkb.Options" type="string">grp:caps_toggle</merge>
    </match>
  </device>
</deviceinfo>

und in die Konfig für die Maus (synaptics-freebsd):
Code:
[root@pinky /usr/local/etc/hal/fdi/policy]# more 102-mouse-input.fdi
<?xml version="1.0" encoding="utf-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.mouse">
      <merge key="input.x11_options.Protocol" type="string">auto</merge>
      <merge key="input.x11_options.Device" type="string">/dev/sysmouse</merge>
      <merge key="input.x11_options.ZAxisMapping" type="string">4 5 6 7</merge>
    </match>
  </device>
</deviceinfo>

Ich hoffe das dies weiterhilft und Euch eine längere Suche erspart.
 
erst mal Dank dafür, das ist hilfreich.

Hattest du Probleme mit einem der Punkte?
Bei mir funktionierte Keyboard und Maus zunächst auf Anhieb, nur beim automatischen Start über KDM werden die nicht angesprochen. Kille ich X und KDM, wird beides automatisch neu gestartet und Maus und Keyboard werden aktiviert, beides USB-Geräte, beide sind ohne X bereits aktiv und funktionieren. Starte ich KDM nicht automatisch sondern von der shell, funktioniert es auch auf Anhieb, nur beim automatischen Start gibt es da irgendeinen Hänger.
Vielleicht probiere ich die Hal-fdis mal aus.
 
Das Problem ist bekannt und kann nur upstream in Xorg gelöst werden. Der einzige Workaround ist den Start von kdm zu verzögern.
 
Das Problem ist bekannt und kann nur upstream in Xorg gelöst werden. Der einzige Workaround ist den Start von kdm zu verzögern.

KDM startet doch normalerweise den X.
Müsste da nicht eine Bremse im KDM eingebaut werden?
Kann mir im Augenblick da nicht vorstellen, wie das gehen soll.
Oder genügt es, dem System einfach etwas mehr Zeit VOR dem Start von KDM zu lassen, damit Hal vielleicht besser alles "ordnen" kann? Bei mir werden (gemäß deiner Empfehlung im WiKi) erst die Schriften aufgenommen, das dauert doch schon eine Weile und verzögert ja bereits den Start von KDM. Deshalb denke ich, daß irgendwie anders gehandhabt werden muss.
 
Die Dinge starten in der richtigen Reihenfolge, wenn aber X startet bevor hald und dbus eine Verbindung miteinander aufgebaut haben, findet X den hald nicht und alles bleibt still. Um das Problem zu lösen muss X einfach länger versuchen sich mit hald und dbus zu verbinden.
 
erst mal Dank dafür, das ist hilfreich.

Hattest du Probleme mit einem der Punkte?

Ja, da die mittlere Maustaste wollte nicht mehr pasten. Und die Umschaltung auf arabisches Ka
eyboard-Layout ging aucgh nicht mehr.

Habe dann gesucht, ob es eine Möglichkeit gibt, die Automatismen bei HAL etwas zu steuern und bin in einem Ubuntu-Forum fündig geworden, allerdings war da die Information nicht nur Linux-lastig, sondern sogar von diesen Ubuntu-versionen abhängig.

Sehr hilfreich sind die Befehle:

hal-find-by-capability --capability input | xargs -I{} hal-device {}
und z.B.

hal-device | grep -i kernel

Um Auskünfte zu erhalten
 
Hi,

langsam kommen mir die Tränen.

Das kann doch nicht so ein Akt sein, dass die Tastatur funktioniert.

Habe 7.1 komplett frisch aufgesetzt und die Port auf den aktuellen gebracht und kompiliert.

Das Keyboard-File ist wie oben beschrieben unter /usr/local/etc/hal/fdi/policy angelegt.

Die xorg.conf habe ich frisch mittels X -configure erzeugen lassen. X startet, Gnome startet. Tastatur funzt nicht.

Bekomme folgende Meldung von Xorg

(**) Option "Device" "/dev/ukbd0"
(EE) product 0x1400: cannot open "/dev/ukbd0"
(II) UnloadModule: "kbd"

Bitte um Rettung
 
aus meiner log:
(II) config/hal: Adding input device USB-Keyboard
(II) LoadModule: "kbd"

(II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
compiled for 1.5.3, module version = 1.3.2
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.1
(**) USB-Keyboard: always reports core events
(**) Option "Protocol" "standard"
(**) USB-Keyboard: Protocol: standard
(**) Option "Device" "/dev/ukbd0"
(EE) USB-Keyboard: cannot open "/dev/ukbd0"
(EE) PreInit failed for input device "USB-Keyboard"
(II) UnloadModule: "kbd"
(EE) config/hal: NewInputDeviceRequest failed
(II) config/hal: Adding input device Microsoft IntelliMouse? Explorer
(II) LoadModule: "mouse"

(II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
compiled for 1.5.3, module version = 1.4.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.1
(**) Option "Protocol" "auto"
(**) Microsoft IntelliMouse? Explorer: Device: "/dev/sysmouse"
(**) Microsoft IntelliMouse? Explorer: Protocol: "auto"
(**) Microsoft IntelliMouse? Explorer: always reports core events
(**) Option "Device" "/dev/sysmouse"
(==) Microsoft IntelliMouse? Explorer: Emulate3Buttons, Emulate3Timeout: 50
(**) Option "ZAxisMapping" "4 5 6 7"

das sieht alöso genau gleich aus, funktioniert aber.
Dabei nutze ich KDM und KDE, nicht aber Gnome.
Meine Probleme wie oben bestehen noch, obwohl es fast täglich Updates zu X und Hal gibt. Ich boote normalerweise nicht, sodaß ich hier nicht unnötig investiere, nur, zuletzt habe ich eine ziemliche Serie mit Abstürzen und dadurch öfter die Gelegenheit, die Sache zu checken. Bei mir wird also automatisch kdm gestartet und damit auch X und es geht dann keine Tastatur und keine Maus.
Mit ALT+F1 logge ich mich ein (oder remote), setze einen kill -9 `pidof kdm-bin` `pidof Xorg` && exit ab und schon geht es und kdm startet automatisch neu, mit Maus und kbd.
 
Nach stöbern im Internet bin ich auf folgenden Eintrag gestolpert
Code:
Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
[COLOR="Blue"]	Option		"AllowEmptyInput" "False"[/COLOR]
EndSection

Danach funzt zumindest die Tastatur. Wenn auch unglaubliche Delay bei der Eingabe vorkommen.

Xorg 7.4 ist einfach nur eine Zumutung. Werde mir nun wieder die älteren Packages installieren.
 
Option "AllowEmptyInput" "boolean"
If enabled, don't add the standard keyboard and mouse drivers,
if there are no input devices in the config file. Enabled by
default if AutoAddDevices and AutoEnableDevices is enabled, oth-
erwise disabled. If AllowEmptyInput is on, devices using the
kbd or mouse driver are ignored.

das ist aber doch ein guter Hinweis, wie ich finde. Jedenfalls wollte ich damit auch schon was probieren. AutoAddDevices and AutoEnableDevices meine ich dabei. Wenn Hal doch die Daten (mit dbus) an den X-Server übergeben soll, dann macht das doch vielleicht Sinn? Dann kann das vielleicht auch im laufenden Betrieb einfach gewechselt werden (ok, das konnte es eigentlich ja bei USB auch nun schon).
Ich gebe dir aber Recht, das ist für mich auch Geraffel und ich verstehe nicht, wieso diese Abhängigkeit von Hal und Konsorten da nun sein mußte.
 
Ein Hinweis auf eine nachvollziehbare Doku in UPDATING wäre wohl zuviel gewesen. RTFM mach ich schon mal, wenn man mich darauf hinweist.

Aber dieses Gesuche und Probieren nervt nur noch. In diesem Forum und auch in dem neuen FreeBSD.org Forum sind etliche Leute, die Probleme bekommen haben. Irgenwo liest man mach dies oder jehnes. Wonirgens wird mal in einfacher Weise dargestellt, wie das ganze zu bewerkstelligen ist - für jemanden der nicht Compilerbau als Schwerpunktfach gehabt hat.
 
Danach funzt zumindest die Tastatur. Wenn auch unglaubliche Delay bei der Eingabe vorkommen.
Das habe ich auch festgestellt.

Habe den Eintrag wieder entfernt. Für hal Optionen bin ich gemäss chruetertee.ch vorgegangen. Inhaltlich sind das File 99-x11-keyboard.fdi (chruetertee) und 101-keyboard-input.fdi (georg) nahezu identisch, weiss aber nicht ob der unterschiedliche Name einen Einfluss hat.

Das Update auf X.org 7.4 lief wirklich nicht sehr gut ab.

mousaka
 
Es gibt keine nachvollziehbare Doku, da kann man niemanden einen Vorwurf machen. Das Bisschen war existiert haben die FreeBSD Porter selbst geschrieben, um überhaupt etwas in der Hand zu haben. Was die Delays bei der Eingabe betrifft, sie treten nicht auf wenn du beim Tippen die Maus bewegst? Das ist ein bekannter Bug in X.org, der labidare Kommentar der Entwickler: "Just use evdev". Den gibt es leider nur für Linux, andere Plattenformen sind wohl nicht mehr im Fokus der Entwicklung *schulterzuck*. Bei mir war das Problem verschwunden, nachdem ich Hal komplett deaktiviert hatte. Also wirklich den Prozess abgeschossen.
 
das wird ja langsam ein anti-Hal thread.
Deshalb: Hal kam gerade in Mode, als es unter Linux gute Lösungen für automatisches Einbinden von Laufwerken mit Hilfe von Scripts und automountd gab (wie Kamikaze das nun auch für FreeBSD realisiert hat). Mein persönlicher Werdegang verlief so, daß ich etwa zu dem Zeitpunkt zu FreeBSD wechselte. Hal lernte ich also nicht mehr unter Linux kennen, doch Kollegen erklärten mir, wie sehr sie damit zufrieden sind. Das kann für FreeBSD nicht gelten.
Zunächst begrüßte ich, daß die Möglichkeit nun auch für mich verfügbar war, denn damit konnte ich anderen eine automatische Einbindung ihrer Wechselgeräte ermöglichen, was da stets begrüßt wurde. Das einfache nachsehen, wie das Gerät erkannt wird und dann das Absetzen eines manuellen mount Befehls schreckt viele, für mich vollkommen unverständlich. Nur dafür habe ich Hal genutzt.
Hal hat aber weitergehende Ideen, er macht ja sehr viel mehr, als nur nach Wechselmedien zu schauen. Im Grunde genommen macht er das sogar relativ unbeholfen und gar nicht sonderlich zuverlässig. Die Ziele des Projektes in Ehren, HAL, also die Hardware komplett zu abstrahieren, das mag was sein, das Plattformübergreifende Normen bringen kann, doch für uns macht doch ein Kernel genau das schon ohne hin und ganz besonders, wenn er noch zur Laufzeit ladbare Module haben kann. Das ist natürlich ein wenig gefährlicher für das System, doch lieber investiere ich doch darein, als daß ich mir ein zusätzliches System von System-Meldungen und Aktionen überstülpen muß, das ziemlich aufwendig und manchmal nicht einfach nachvollziehbar über das Betriebs-System verteilt läuft. Und dann kommt da noch die eher nachlässige Unterstützung für andere Plattformen als Linux hinzu. Das kann kaum gut werden.
Passend aber in Richtung X-Entwicklung. Die ist genauso unsinnig und nur Linux-lastig. Statt halbwegs funktionierende Lösungen zu entstören und dafür zu sorgen, daß die wirklich glatt laufen, werden dauernd neue Gimmiks eingebaut, die aber auch den allgemeinen Gebrauch und die Performance nicht verbessern. Ganz ehrlich hatte ich mit dem alten X-Free deutlich bessere Ergebnisse mit sehr viel schwächerer Hardware. So konnte ich früher ungestört Filme ansehen und brauchte noch nicht mal die AGP Graka mit 4MB dazu, während nun die gleichen Filme doch nicht vollkommen ohne Störungen laufen, aber auf zehnfach schnellerer HW. Diese Störungen kamen ungefähr zeitgleich mit Xorg, oder doch mit Redhat-Xorg und sind niemals besser geworden. Manchmal frage ich mich, ob ich hauptsächlich einen schnellen Rechner brauche, damit ich die Gier von X befriedigen kann.
Es gab da mal Projekte, Unix ohne X-Server aber auch grafisch zu betreiben.
Für einen Desktop User ist ein X-Server ja auch zu viel, das muß nicht wirklich so sein. Vielleicht denkt ja jemand an so was, bei so viel Ärger?
 
Zurück
Oben