Maus funktioniert plötzlich nicht mehr in KDE4.8

cabriofahrer

Well-Known Member
Auf einem frisch installierten KDE4.8 ist plötzlich beim Surfen im Internet mit seamonkey und einem portinstall im Hintergrund plötzlich der Desktop eingefroren. Als ich mehrere "Strg-Alt+F1.." versuchte, ist das Notebook plötzlich abgeschmiert und hat einen Neustart gemacht und anschließend ein fsck erfolgreich durchgeführt. Doch plötzlich funktionierte das Mauspad in KDE nicht mehr. Wenn ich jedoch in ein Terminal (z.B."Strg-Alt-F2") wechsele, funtioniert die Maus. Es liegt also nicht an der Notebook-spezifischen Mauskombination, mit der man das Mauspad tatsächlich abschalten kann. Ich habe KDE/X gekillt, und ein "startx" gemacht, und auch hier funktioniert die Maus. Nur eben unter KDE plötzlich nicht mehr. Ich habe die Ordner .kde und .kde4 gelöscht, doch immernoch das gleiche: Die Maus funktioniert einfach nicht mehr in KDE. Vielleicht irgendeine Tastenkombination, oder was ist hier los?
 
öffne mal einen Terminal, wenn die Maus gerade nicht geht und mach dort als root
Code:
service dbus restart
Seit dem letzten Upgrade geht bei jedem zweiten Start meine Maus auch nicht, nachdem dbus-restart gehts dann aber wieder, kA warum. Ich benutze auch noch den alten Xorg...
 
Tatsächlich, nach einem von mehreren Neustarts hatte es plötzlich wieder funktioniert und dann wieder nicht. Der Befehl zum Neustart funktioniert. Ein "dmesg -a | grep dbus" ergibt folgendes:

elvis69# dmesg -a | grep dbus
cardbus0: <CardBus bus> on cbb0
cardbus1: <CardBus bus> on cbb1
cardbus2: <CardBus bus> on cbb2
Starting dbus.
Starting dbus.
Failed to start message bus: The pid file "/var/run/dbus/dbus.pid" exists, if the message bus is not running, remove this file
/etc/rc: WARNING: failed to start dbus
elvis69#

Was also jetzt tun? die Datei dbus.pid einfach löschen?
 
Hier das gleiche Problem: Am Freitag wieder mal die Pakete mit pkg_upgrade auf den neuesten Stand gebracht und seitdem gibt es beim Hochfahren Probleme mit der Maus. Ich wechsele dann zu einer Konsole, kille X, der dann selbst neustartet und dann läuft auch die Maus wieder.
 
Ich hatte nach dem Update auch Probleme mit meiner Maus. Ich habe dann spontan mal eine weitere USB-Maus angeschlossen und siehe da es klappte wieder. Seit dem ich aber noch einmal alle Ports neugebaut habe, sind keine Probleme mehr aufgetaucht.
 
Mein Dbus wird nur einmal gestart und trotzdem muss ich zufällig ab und zu neustarten um meine Maus benutzen zu können.
 
Da mir das nach einem Absturz während eines "portmaster --packages-if-newer www/chromium" passiert ist, kann es nicht sein, daß da irgendetwas kaputt ist?

Wie kann ich prüfen, ob:

1. installierte ports / packages vielleicht beschädigt sind?

Portmaster hat sicherlich einiges aktualisiert, also

2. herausfinden, welche Abhängigkeiten / Versionen von ports / packages kde4 und xorg erwartet werden und feststellen, daß einige neuere Versionen haben?
 
Bei mir werden auch komischerweise dbus, hal und fuse versucht mehrmals zu starten beim hochfahren. Irgendwie das meiste was in der rc.conf drinsteht. Die meisten Dienste beschweren sich dann dass es ihr PID File schon gibt.

Ausserdem habe ich auch Probleme mit der Maus. Das tritt seit gestern auf, ich hatte ein portmaster digikam laufen. Er aktualisierten neben den kde libs auch hal. Irgendwie glaub ich das dies der Übeltäter ist. Ich meine mich zu erinnern das ich das Problem mit Maus/Tastatur schon mal hatte. Dem hal haben damals Config Dateien gefehlt.
 
Portmaster ist ein Übeltäter. Es aktualisiert gleich alle Abhängigkeiten mit, danach kommt es zu Problemen. Man würde ja auch erstmal kein portupgrade -R machen, um etwas zu installieren oder einen bestimmten port zu aktualisieren.
Zu dem Problem mit der Maus bleibt einem hier wirklich nichts anderes übrig, als kde4 komplett neu zu aktualisieren, jetzt eben mit portmaster oder durch ein portupgrade -R kde4 oder eben gleich alle ports. Da mußte ich jetzt auch durch.

Zum doppelten Starten von Diensten: Der Eintarg

local_startup="${local_startup} /usr/local/kde4/etc/rc.d"

muss raus aus rc.conf
 
das Problem mit der maus konnte ich jetzt lösen. Ich hab hal und dieses hal-info paket neu installiert. Danach startete der hal daemon wieder.

Ok ich werde die zeile bei mir rausnehmen. Aber wie starte ich dann kdm?
 
Also bei mir wird nichts doppelt gestartet, ich benutze kein KDM und kein KDE-Desktop, und habe das Problem trotzdem.
 
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
 
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.
 
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).
 
@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...
 
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.
 
Habt ihr, nachdem ihr X wieder beendet habt, auch folgendes auf dem Bildschirm stehen?

Code:
Current version of pixman: 0.24.2
        Before reporting problems, check [URL]http://wiki.x.org[/URL]
        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

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?
 
Code:
(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:

Code:
(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/handbook/x-config.html)
Code:
Option "AutoAddDevices" "false"
zu setzen und von Hand die /dev/sysmouse zu setzen. Bei mir gibt es dazu im Augenblick nur diese:
Code:
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>
 
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:
Code:
Section "ServerFlags"
	Option "AllowEmptyInput" "false"
EndSection

2. Klassische Konfiguration rein:
Code:
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.
 
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.
 
Zurück
Oben