Maus funktioniert plötzlich nicht mehr in KDE4.8

[zwei]

Hallo,

ich habe dieses Problem auch. Es trat zum ersten Mal auf, als vor kurzem das Xorg-Update rauskam. Zuerst trat das Problem unter FreeBSD 8.2 auf, aber seit wenigen Tagen habe ich es auch unter FreeBSD 9.0. Auch nach aktualisieren auf das aktuelle Xorg. Am Anfang schien das Problem gelöst zu sein, als ich meine Maus über PS2 statt USB anschloss, was sich aber jetzt als falsch rausgestellt hat. Auch eine neue, frische xorg.conf konnte das Problem nicht lösen. Was mir noch aufgefallen ist:

Unter FreeBSD 8.2 tritt das Problem immer auf. Ich muss immer meinen WM 1x neustarten. Unter FreeBSD 9.0 tritt es nur unregelmäßig auf.

Edit: Bei mir werden auch keine Dienste doppelt gestartet, zumindestens nicht unter FreeBSD 9.0. Benutze auch kein KDM/KDE.

@cabriofahrer

Wieso sollte ich die Abhängigkeiten eines Ports nicht mitaktualisieren?

Ich gehe immer so vor:

#csup /usr/local/etc/csup/ports-supfile
#pkg_version -v | grep need

Dann aktualisiere ich entweder manuell

# portupgrade -rv port

oder alles mit

#portupgrade -arv

[pit234a]

ich kann das für FreeBSD 8.3 grundsätzlich auch bestätigen.
Allerdings habe ich noch kein bisschen nachgesehen, es gab ganz ähnliche Probleme schon mal nachdem X auf Hal setzte und da ein paar Dinge konfiguriert werden mussten. Die xorg.conf und eine der Hal-fdi mussten damals angepasst werden, wenn ich das recht erinnere.
Hal macht immer wieder derartige Probleme und überschreibt einfach die gefundenen Einstellungen mit default-Settings, deshalb würde ich hier mal anfangen.

Das Problem tritt nicht regelmäßig auf, aber nahezu immer und es verschwindet nahezu immer, wenn X dann neugestartet wird.
Nebenbei: das geht auch nicht mit ctrl+alt+backspace, wie es in meiner xorg.conf drin steht. Auch das ein Hinweis auf ein Problem wegen Hal-Update.

[pit234a]

erst zweimal probiert, aber beide Male erfolgreich verlief bei mir ein Start ohne xorg.conf.
Ich bin da nicht ganz sicher, was genau passiert, ber die neuen Xorg brauchen keine conf mehr und erledigen die Konfiguration mitunter automagisch während des Startes und dann scheinen sie auch die jeweiligen einträge in den fdi-Dateein des hal zu berücksichtigen.
oder anders gesagt, kann ich mir vorstellen, dass mit einer xorg.conf der X-Server so schnell gestartet wird, dass ihm die entscheidenden Informationen vom HAL noch fehlen.

Mein Ansatz war daher, es so zu versuchen, dass ich Xorg nicht automatisch über den Aufruf von KDM aus /etc/ttys starte, sondern dies manuell erledige. Die wenigen Aufrufe, die ich probierte, funktionierten immer auf Anhieb mit Maus.
Dann benannte ich die xorg.conf um, sodass in /etc/X11 keine gültige gefunden wird und lasse den kdm wieder automatisch starten. Ich nehme an, dass nun beim Start des X-Servers durch die diversen Auto-Proben länger gebraucht wird und dadurch Hal sich gültig einmischen kann.
Wie gesagt, erst zwei Versuche, aber die waren auf Anhieb erfolgreich.
Einen guten Grund, X nicht auf diese Art automagisch konfigurieren zu lassen, sehe ich schon, aber ich kann damit durchaus auch leben, weil es doch einfacher ist, nur etwas länger zu warten, als den X-Server bei beinahe jedem Boot killen zu müssen.
Also, zwei Versuche, das langt natürlich nicht, aber ich habe nicht vor, den PC heute nochmal neu zu starten. Deshalb wollte ich dies schon mal loswerden, vielleicht wirkt das ja auch bei euch. (Oder eben nicht und dann wisen wir vielleicht auch ein wenig mehr).

[SolarCatcher]

@pit234a
Deine Beobachtungen würden vielleicht meine eigenen erklären helfen. Ich stelle fest, dass ich Xorg immer(!) neustarten muss, wenn ich meinen Laptop unterwegs nutze - aber fast nie, wenn er in seiner Dockingstation sitzt. Vermutlich braucht im Bootprozess die Konfiguration der zusätzlichen Hardware (Dockingstation selbst + USB Tastatur + USB Trackball) genügend Zeit, damit Xorg dann schon die Informationen von Hal bekommt, die Du da vermutest...

[pit234a]

zuverlässig funktioniert es allerdings bei mir noch nicht.
Das Verhalten ist deutlich besser geworden, etwa genau vertauscht. Vorher gingen 90% schief, nun gelingen 90%. Das ist immerhin schon mal was.

[zwei]

Habt ihr, nachdem ihr X wieder beendet habt, auch folgendes auf dem Bildschirm stehen?

Current version of pixman: 0.24.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 21 09:04:50 2012
(==) Using config file: "/etc/X11/xorg.conf"
(EE) xf86OpenSerial: Cannot open device /dev/ums0
        Device busy.
(EE) USB Optical Mouse: cannot open input device
(EE) PreInit returned NULL for "USB Optical Mouse"
(EE) config/hal: NewInputDeviceRequest failed (8)
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
>                   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
xinit: connection to X server lost

waiting for X server to shut down .
xauth: (argv):1:  bad display name "foo:0" in "remove" command

Auch längeres warten >2 Minuten, hilft nicht, um den Neustart zu umgehen.

[cabriofahrer]

Zitat von zwei

@cabriofahrer

Wieso sollte ich die Abhängigkeiten eines Ports nicht mitaktualisieren?

Ich habe nicht gesagt, daß Du das nicht solltest, aber ich habe damit schlechte Erfahrungen gemacht. Oftmals funktioniert danach irgendetwas nicht mehr, nur weil ich beispielsweise nur meinen Seamonkey Browser aktualisieren wollte.

Bei mir scheint nach Neukompilieren von hal und hal-info das Problem (fast) weg zu sein, es kommt selten vor, daß die Maus nicht mehr funktioniert. Und wenn, dann kann man eben durch ein

service dbus restart

schnell Abhilfe schaffen. Doch heute ist mir etwas Neues aufgefallen:

Ich habe das Notebook mal nur mit Akku betrieben, und die Maus in KDE ging partout nicht, weder mit Neustart von dbus noch mit kompletten Neustart. Was hat das nun zu bedeuten? Schlägt das in dieselbe Kerbe wie das, was Ihr berichtet?
Habe keine Fehlermeldung im Zusammenhang mit pixman in meiner Xorg.log sehen können. Wozu ist überhaupt da pixman da?

[pit234a]

(EE) xf86OpenSerial: Cannot open device /dev/ums0
(EE) Microsoft IntelliMouse Explorer: cannot open input device
(EE) PreInit returned NULL for "Microsoft IntelliMouse Explorer"
(EE) config/hal: NewInputDeviceRequest failed (8)

das ist im Fehlerfall bei mir gewesen und der Fehlerfall kommt übrigens wieder häufiger, war wohl vorher ein statistischer Ausrutscher, als es so oft hintereinander gut gegangen war.

Wenn ich dann den X-Server neu startete, wurde das Gerät als /dev/sysmouse richtig erkannt und eingebunden und funktionierte.
Es ist eine USB-Maus und als es heute Morgen wieder mal nicht funktioniert hatte und ich mich aber bereits eingelogged hatte und alle Applikationen schon gestartet waren, da habe ich die Maus abgezogen und neu gesteckt und sie funktionierte dann. Ich zeige mal den Log:

(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.7.7, module version = 1.7.1
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 7.0
(WW) Microsoft IntelliMouse Explorer: No Device specified, looking for one...
(II) Microsoft IntelliMouse Explorer: Setting Device option to "/dev/ums0"
(--) Microsoft IntelliMouse Explorer: Device: "/dev/ums0"
(==) Microsoft IntelliMouse Explorer: Protocol: "Auto"
(**) Microsoft IntelliMouse Explorer: always reports core events
(**) Option "Device" "/dev/ums0"
(EE) xf86OpenSerial: Cannot open device /dev/ums0
        Device busy.
(EE) Microsoft IntelliMouse Explorer: cannot open input device
(II) UnloadModule: "mouse"
(EE) PreInit returned NULL for "Microsoft IntelliMouse Explorer"
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device AT Keyboard
(II) LoadModule: "kbd"
.....
.....
.....
(II) RADEON(0):         005032302d310a2020202020202000ad
(II) RADEON(0): EDID vendor "FUS", prod id 1152
(II) config/hal: Adding input device Microsoft IntelliMouse Explorer
(WW) Microsoft IntelliMouse Explorer: No Device specified, looking for one...
(II) Microsoft IntelliMouse Explorer: Setting Device option to "/dev/sysmouse"
(--) 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"
(**) Microsoft IntelliMouse Explorer: ZAxisMapping: buttons 4, 5, 6 and 7
(**) Microsoft IntelliMouse Explorer: Buttons: 11
(II) XINPUT: Adding extended input device "Microsoft IntelliMouse Explorer" (type: MOUSE)
(**) Microsoft IntelliMouse Explorer: (accel) keeping acceleration scheme 1
(**) Microsoft IntelliMouse Explorer: (accel) acceleration profile 0
(II) Microsoft IntelliMouse Explorer: SetupAuto: hw.iftype is 4, hw.model is 0
(II) Microsoft IntelliMouse Explorer: SetupAuto: protocol is SysMouse

Das wird sicher den Kundigen hier was sagen. Vielleicht wissen die dann, was da abgeht.
Meine Meinung ist nach wie vor, dass zur rechten Zeit HAL noch nicht mit passenden Informationen aufwartet. Da gab es einen ähnlichen oder sogar den gleichen Fehler in einer älteren Xorg-Version schon mal.

Ich habe auch nicht weiter danach gesucht, ich denke, dass es da schon entsprechende Einträge in den Mailinglisten gibt.

Außerdem habe ich nicht probiert, die xorg.conf genau anzupassen und hier die Maus zu konfigurieren, also dann die (http://www.freebsd.org/doc/de/books/.../x-config.html)

Option "AutoAddDevices" "false"

zu setzen und von Hand die /dev/sysmouse zu setzen. Bei mir gibt es dazu im Augenblick nur diese:

pit@syo ~:-> cat /usr/local/etc/hal/fdi/policy/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>

[Yamagi]

Ich habe das nun alles durchgelesen, aber eines wird mir nicht klar: Wieso zu Hölle nutzt ihr den "hald"? Das Ding funktionierte noch nie zuverlässig, aus gutem Grund haben die Linuxer es wieder rausgerissen. Unter FreeBSD ist er für X.org meist sowieso unnötig, da das System selbst durch seine Abstraktion das Hotplugging von Mäusen und Tastaturen bereits unterstützte, als X11 davon nur träumen konnte... Einziges Argument dagegen sind von psm(4) nicht unterstützte Touchpads.

Daher 3 Schritte zur Glücksseligkeit:

1. hald abschalten:

Section "ServerFlags"
	Option "AllowEmptyInput" "false"
EndSection

2. Klassische Konfiguration rein:

Section "InputDevice"
	Identifier  "Mouse0"
	Driver		"mouse"
	Option		"Protocol" "SysMouse"
	Option		"Device" "/dev/sysmouse"
EndSection 

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "de"
    Option      "XkbVariant" "nodeadkeys"
	Option      "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

3. Abschließend moused(4) in der rc.conf einschalten (nur für PS/2-Mäuse notwendig) einschalten. Der Keyboard-Multiplexer kbdmux(4) ist standardmäßig eingeschaltet.

[pit234a]

Zitat von Yamagi

Ich habe das nun alles durchgelesen, aber eines wird mir nicht klar: Wieso zu Hölle nutzt ihr den "hald"?

Du hast ganz gewaltig Recht und ganz sicher bin ich kein Freund von HAL und bin es auch für Linux nie gewesen.
Zu irgendeiner Zeit wollte ich eine elegante Möglichkeit, Geräte zur Laufzeit automatisch einbinden zu können. Damals kannte ich nur HAL und eben dbus dafür. Ich mochte es nie, kam aber soweit damit zu Recht, dass ich es sehr gut dafür einsetzen konnte. Wenn es denn mal drauf ist und läuft, kann so manche Anwendung auch diesen Dienst nutzen (mehr oder weniger gut).
Deshalb ist es nun bei meinem System keine Frage, dass ich dabei bleibe, es nicht mehr ändere. Dies ist inzwischen ein "alter PC" (> 5 Jahre), auf dem ich bei FreeBSD 8er bleiben werde und KDE3 weiter nutze, bis er nicht mehr geht.

Bei neuen Installationen ließ ich HAL vollkommen weg und war ohne Automatismen beim Mounten glücklich. Wenn ich aber keinen Fehler im Hinsehen machte, dann hatte mir bei OpenBSD auch ohne Automatismen doch irgendeine Anwendung auch einen hald installiert. So genau habe ich nicht hingesehen, aber es geht scheinbar schneller, als man denkt, dass man sich da was einfängt.

[Yamagi]

Ich meinte "hald abschaffen" nur auf X.org bezogen. Nicht auf die Fensterumgebung die darin läuft. Die kann damit natürlich gern weiter mounten, wenn denn funktioniert.

[cabriofahrer]

Zitat von Yamagi

1. hald abschalten:

Section "ServerFlags"
	Option "AllowEmptyInput" "false"
EndSection

Wenn man das macht, wird KDE 4.8 anscheinend ganz langsam. Habe ich ausprobiert und wird am Rande auch hier erwähnt:

http://forums.freebsd.org/showthread.php?t=32546

Eine Section "ServerFlags" gab es standartmäßig gar nicht in meiner xorg.conf, d.h. die wird wohl anders als früher durch "Xorg -configure" auch nicht mehr erzeugt?

[Fusselbär]

Auszug aus meiner /etc/X11/xorg.conf:

Section "ServerFlags"
    Option         "AutoAddDevices" "False"
    Option         "AllowEmptyInput" "Off"
EndSection

Damit flitzt KDE4 bei mir ganz vorzüglich auf FreeBSD 9.0-STABLE amd64.
Aber auch mit HAL Daemon für die Eingabegeräte läuft es. Auch Automount mit USB-Laufwerken und CD/DVD Laufwerken tut es bei mir.
Dafür müssen jedoch die *.fdi Dateien unter:
/usr/local/etc/hal/fdi/policy/
korrekt sein.
http://www.bsdforen.de/showpost.php?...3&postcount=17

An diesen kürzen HAL-Rülpser vor ein paar Wochen kann ich mich aber auch erinnern,
der Firefox nutzt ja ebenfalls HAL und da blockierte während des updaten mal kurzfristig die Maus.
Hatte dann den Firefox beendet und neu geöffnet, dann tat es auch der Mauscursor wieder.

[carbuncle]

cabriofahrer> Ich kann das bestaetigen, bei mir wird Windowmaker auch langsam und traege

[cabriofahrer]

Zitat von Fusselbär

Auszug aus meiner /etc/X11/xorg.conf:

Section "ServerFlags"
    Option         "AutoAddDevices" "False"
    Option         "AllowEmptyInput" "Off"
EndSection

So funktioniert es (scheinbar nach mehreren boots) bei mir jetzt auch zuverlässig. An fdi-Dateien habe ich noch nie was gemacht.