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

Du meinst die Konvention ist, daß das erste Bit Bit 0 ist?
Das schließe ich mal aus
Driver Flags
The psm driver accepts the following driver flags. Set them in
/boot/device.hints (see EXAMPLES below).

bit 0..3 RESOLUTION ...
 
daß das erste Bit Bit 0 ist?

Davon ging ich allerdings auch aus. Ob das Konvention ist oder in der von dir zitierten Man-Page anders gesehen wird, weiß ich nicht. Aber das 14te Bit ist "normalerweise" 2^13 und das erste Bit 2^0.
Das "nullte" von irgendwas gibt es "normalerweise" gar nicht, auch nicht das nullte Bit.
Bit "0" ist allerdings beinahe eindeutig* und wenn das in der man so steht...

* es könnte auch das Bit mit Wertigkeit "0" gemeint sein, dann wäre Bit 4 also 2^2 = 100(Bin) und damit das dritte Bit. Da es aber kein Bit mit Wertigkeit "3" gibt, verbietet sich diese Interpretation.
 
Bit 0 heißt das Bit das 2^0 kodiert. Bit 12 heißt 2^12. Die Bits einer 32 Bit Zahl werden von 0 bis 31 durchnummeriert.

Eure Zählung mit 1., 2., 3. Bit ist nicht üblich.
 
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

Also nochmal:
1800 <=> 01 1000 0000 0000 -> Bit 11 und 12 gesetzt
2000 <=> 0010 0000 0000 0000 -> Bit 13 gesetzt
3000 <=> 0011 0000 0000 0000 -> Bit 12 und 13 gesetzt

Laut Manpage kann man auch
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.

=> 0100 0000 0000 0000 <=> 4000

Also gäbe es noch die Möglichkeit, die Flags zur Lösung des Problems auf 0x4000 zu setzen.

@Kamikaze
Danke für den Auffrischungskurs!
 
Nach ein paar Tagen testen scheint die Lösung darin zu liegen, in die /etc/rc.suspend gar nichts zu schreiben.

In der /etc/rc.resume über /usr/sbin/service moused restart, die Maus neu zu starten.
(Hier scheint die Reihenfolge in der Datei noch wichtig zu sein. Bei mir steht es jetzt am Schluß, was die Sache vermutet zuverlässiger macht)

In der /boot/device.hints hint.psm.0.flags="0x3000" zu setzen.

In /etc/sysctl.conf hw.usb.no_suspend_wait=1 zu setzen.

Danke für die geduldige Hilfestellung!
 
Ich denke nicht, dass hw.usb.no_suspend_wait relevant ist. Desweiteren sollte das Neustarten des moused-Diensts auch nicht nötig sein. Und 0x3000 sind wie bereits erörtert falsch. Entweder 0x2000 (13. Bit gesetzt) oder 0x4000 (14. Bit gesetzt).

Teste doch nochmal durch, ob es auch nur mit Setzen des hint.psm.0.flags geht, ohne das andere Geraffel.

Rob
 
hw.usb.no_{suspend,shutdown}_wait ist trotzden anzuraten, weil dadurch der Rechner schneller schläft / herunterfährt.
 
Und 0x3000 sind wie bereits erörtert falsch.


https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/ACPI-debug.html
Dann ist das, was da unter 12.14.3.1. Mausprobleme steht falsch? Die empfehlen nämlich die 0x3000.

Entweder 0x2000 (13. Bit gesetzt) oder 0x4000 (14. Bit gesetzt).

OK.

Teste doch nochmal durch, ob es auch nur mit Setzen des hint.psm.0.flags geht, ohne das andere Geraffel.

Mach ich, dauert aber natürlich was, mit 0x2000 ging es definitiv nicht und mit der 0x3000 funktioniert es, so wie es oben steht. Ich nehme mal die 0x4000 und teste damit.
 
Das einzige, was ich rauswerfen kann, ist der Eintrag der flags in der /boot/device.hints ... sobald ich den Neustart der Maus aus /etc/rc.resume nehme, kommt die Maus nicht wieder zurück. Es scheint auch egal zu sein, was ich da unter flags angebe. 0x2000, 0x3000 oder 0x4000. Ich nehme mal an, daß das mit dem überragenden BIOS von Lenovo zu tun hat.

Code:
# cat/etc/rc.resume
...
/usr/bin/logger -t $subsystem resumed at `/bin/date +'%Y%m%d %H:%M:%S'`
/bin/sync && /bin/sync && /bin/sync

# mouse start
/usr/sbin/service moused restart

exit 0
 
Zurück
Oben