/etc/rc.suspend will nicht so, wie ich wohl will ...

peterle

peterle

Forenkasper
Ich habe immer noch einen X220 und aktuell FreeBSD 10.3 darauf.

Nachdem ich denEindruck hatte, daß suspend und resume funktionieren, muß ich leider feststellen, daß die Maus nicht wieder zum Leben erwacht, sondern tot in der Ecke hängt.
Das läßt sich problemlos mit einem

Code: 
# service moused restart

ändern.

Also ist die logische Konsquenz, in /etc/rc.suspend ein

Code: 
# service moused stop

und in /etc/rc.resume ein

Code: 
# service moused start

zu schreiben.

Tolle Sache, bringt nur nichts ... Nun könnte man meinen, daß die rc.* gar nicht abgearbeitet würden, aber das werden sie, denn ein einfaches echo mit einer Meldung in /var/log/messages kommt genau da an, wie es soll.

Nun suche ich Hinweise, wie ich das lösen kann, bzw. den Fehler weiter eingrenzen kann?
Danke.
 
Ansonsten würde ich es mal mit dem vollen Pfad probieren:
Code: 
/usr/sbin/service moused stop
Die rc-Scripte haben /sbin und /usr/sbin nicht im Standard-Pfad, wenn ich mich recht erinnere.
 
Ja, in den rc.{suspend,resume} sollte man immer absolute Pfade benutzen.
 
Das alleine reicht leider nicht. Ich hatte auch /etc/rc.d/moused stop/start ausprobiert, aber das hat denselben Effekt.
 
vielleicht mit einer gewissen Pause nach dem resume?
Mein Gedanke: wenn es manuell funktioniert, sollte auch der Aufruf funktionieren. Ein möglicher Unterschied ist, dass der Aufruf sofort abgearbeitet werden kann, deine manuelle Eingabe aber erst etwas später erfolgt, nachdem der resume eigentlich schon beendet ist. Vielleicht braucht es ein wenig Zeit, bis die Maus wiederbelebt werden kann.
 
Unter /var/run hält sich eine pin für die mouse und so nehme ich mal an, daß sie noch nicht einmal abgeschaltet wird.

Ich vermute auch, daß das Probleme der Zeit sind, wann die Maus gestartet bzw. gestoppt wird. Ich weiß nur nicht, wie ich das ändern kann bzw. soll?
 
ich würde das mit einem script versuchen.
Also, aus der rc.resume ein script aufrufen und darin einfach ein sleep setzen.
 
Wie wärs, wenn du versuchst die Ursache zu bekämpfen und die Einträge in der /boot/device.hints ausprobierst?

Rob
 
Irgendwie hatte ich deinen ersten Post wohl überlesen. Sorry.

Was ist denn der Unterschied zwischen 0x2000 und 0x3000?
 
Vermutlich, weil ich nicht alles darin verstehe - entweder bin ich gerade zu dumm oder zu vernagelt.

Die Manpage sagt:
bit 13 HOOKRESUME
The built-in PS/2 pointing device of some laptop computers is
somehow not operable immediately after the system `resumes' from
the power saving mode, though it will eventually become available.
There are reports that stimulating the device by performing I/O
will help waking up the device quickly. This flag will enable a
piece of code in the psm driver to hook the `resume' event and
exercise some harmless I/O operations on the device.

bit 14 INITAFTERSUSPEND
This flag adds more drastic action for the above problem. It will
cause the psm driver to reset and re-initialize the pointing
device after the `resume' event.
Zum Vergrößern anklicken....

Nun vermute ich mal, daß Bit 13 die 0x2000 und Bit 14 durch die 0x3000 dargestellt wird.

In einem anderen Beispiel steht:
hint.psm.0.flags="0x24"

The above line will set the device resolution high (4) and the accelera-
tion factor to 2.
Zum Vergrößern anklicken....

Wie "rechnet" sich das und woher kommt die Definition?
Entschuldigung im voraus, wenn ich schon wieder was übersehen haben sollte.
 
Ich bin vermutlich tatsächlich zu vernagelt. :o
Wenn ich eine Bitreihe mit 14 Bits setze und 12 und 13 setze, dann sieht das so aus: 0000 0000 0001 10 ... Nein, die Reihenfolge ist falsch!

14 Bits mit 12 und 13 gesetzt sind: 01 1000 0000 0000

Wenn ich das richtig in Erinnerung habe, dann sind 4 Stellen Dualsystem eine Hexadezimalstelle*, also sind das 0001 1000 0000 0000 <=> 1800
Mein Bit 14 gesetzt: 0010 0000 0000 0000 <=> 2000
Bit 13 und 14 gesetzt: 0011 0000 0000 0000 <=> 3000

Habe ich da noch einen Fehler drin?
Ich hatte die Reihenfolge für die Bits von links nach rechts statt von rechts nach links angelegt - da scheiterte dann das restliche Verständnis dran, brauche ich alles so selten. :o

* Faustregel:
1111(DUAL) <=> 1*2^3 + 1*2^2 + 1*2^1 + 1*2^0 = 2^3 + 2^2 + 2^1 + 1 = 8 + 4 +2 +1 = 15
 
peterle schrieb:
1111(DUAL) <=> 1*2^3 + 1*2^2 + 1*2^1 + 1*2^0 = 2^3 + 2^2 + 2^1 + 1 = 8 + 4 +2 +1 = 15
Zum Vergrößern anklicken....
= F(Hex) #Oberschlau-Modus

Binär muss man dann aber doch aufpassen, ob das vielleicht im little-Endian-Modus (https://de.wikipedia.org/wiki/Byte-Reihenfolge) benutzt wird oder eben nicht. Das sollte aber nur die Darstellung auf Bitebene betreffen, wenn man etwa den MBR mit Hexdump ausliest und sich dann wundert, dass man die Adressen für die Partitionen gar nicht richtig berechnen kann.
Wenn es hier heißt, Bit 14 setzen, dann sollte das schon so sein, dass damit 2^13 gemeint ist, also 8192(Dez) oder 2000(Hex).
Und sowas macht man natürlich gleich mit Rechner oder etwa Online: http://binaer-dezimal-hexadezimal-umrechner.miniwebapps.de/ und davon gibt es natürlich noch viel mehr.

Ich bin froh, wenn ich diese Bit-Fieselei nicht mehr brauche.
 
Ich habe die flags jetzt auf 3000 stehen und den restart der Maus in der /etc/rc.resume mal ans Ende geschoben => Teilweise funktioniert es, teilweise nicht ...
 
peterle schrieb:
Ich bin vermutlich tatsächlich zu vernagelt. :o
Wenn ich eine Bitreihe mit 14 Bits setze und 12 und 13 setze, dann sieht das so aus: 0000 0000 0001 10 ... Nein, die Reihenfolge ist falsch!

14 Bits mit 12 und 13 gesetzt sind: 01 1000 0000 0000

Wenn ich das richtig in Erinnerung habe, dann sind 4 Stellen Dualsystem eine Hexadezimalstelle*, also sind das 0001 1000 0000 0000 <=> 1800
Mein Bit 14 gesetzt: 0010 0000 0000 0000 <=> 2000
Bit 13 und 14 gesetzt: 0011 0000 0000 0000 <=> 3000

Habe ich da noch einen Fehler drin?
Zum Vergrößern anklicken....
Du fängst bei 1 an zu zählen. Deswegen bist Du überall eine Stelle daneben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben