Tag Archives: suspend

Wenn der BT Adapter einfach wieder ausgeht nach dem Einstecken…

Posted on by

dann macht doch mal das hier:

$ sudo bluetoothctl power on ; sudo systemctl restart bluetooth

Wenn der BT Adapter einfach wieder ausgeht nach dem Einstecken…

Die Ursache könnte nämlich einfach ein kleiner Fehler beim Resume des Betriebssystems sein. Bei mir kamen z.b. im dmesg nur diese Meldungen, wenn ich den Dongle eingesteckt habe:

Abziehen des USB-Dongles:

[759687.061789] usb 1-7.4: USB disconnect, device number 47

Wieder dranstecken:

[759691.418316] usb 1-7.3: new full-speed USB device number 48 using xhci_hcd
[759691.623795] usb 1-7.3: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping
[759691.639775] usb 1-7.3: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[759691.639780] usb 1-7.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[759691.639782] usb 1-7.3: Product: USB2.0-BT
[759691.656175] Bluetooth: hci0: CSR: Setting up dongle with HCI ver=9 rev=0001
[759691.656179] Bluetooth: hci0: LMP ver=9 subver=0001; manufacturer=2279
[759691.656182] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once…
[759691.656184] Bluetooth: hci0: CSR: Couldn’t suspend the device for our Barrot 8041a02 receive-issue workaround
[759691.656189] Bluetooth: hci0: HCI Delete Stored Link Key command is advertised, but not supported.
[759691.656192] Bluetooth: hci0: HCI Read Default Erroneous Data Reporting command is advertised, but not supported.
[759691.656199] Bluetooth: hci0: HCI Set Event Filter command not supported.
[759692.209297] Bluetooth: MGMT ver 1.23

Die Lichter am BT Dongle gingen sofort wieder aus und auch die BT Geräte meldeten sich natürlich nicht. Hintergrund war einfach, daß dem BT Dongle beim Suspend gesagt wurde, daß er mal runterfahren soll und das hat sich der Chip auf dem Dongle doch glatt im Stromlosmodus gemerkt 🙂  Würde man so nicht erwarten, bei etwas was man in den USB Port steckt, oder?

Mit den Kommandos:

$ sudo bluetoothctl power on ; sudo systemctl restart bluetooth

sagt man der BT Hardware, sie soll den BT Controller einschalten und vorsichtshalber bringen wir im Bluetoothstack noch mal alles auf „normal“ 😉

Und dann kommt auch bei Euch vielleicht wieder derartige Zeilen:

[759877.166735] input: Soundcore A1 (AVRCP) as /devices/virtual/input/input20
[759932.072472] input: Soundcore A1 (AVRCP) as /devices/virtual/input/input21

Pinephone: DANKE ModemManager!

Posted on by

Liebe Linuxphone Fans, es ist passiert! Ich habe mich geirrt und freue mich darüber 😀

Pinephone: DANKE ModemManager!

Die ModemManagerelease 1.16.x kommt mit einer Option daher, die das Pinephone aus dem Winterschlaf holt bzw. es gar nicht erst schlafen lässt. Die Konsequenz ist, das Pinephone verpennt im Tiefschlaf keine Anrufe oder SMS mehr.

Zusammen mit dem aktuellen Fedora Megi-Kernel läuft das Pinephone jetzt wie ein „normales“ Smartphone stundenlang, weil es nicht mehr läuft, wenn es nicht mehr gebraucht wird.

Dabei kann Euch dieses kleine Projekt helfen:

https://github.com/Cyborgscode/pinephone/tree/main/suspendguardian

Das schickt das PinePhone nämlich nach 30 Sekunden Bildschirm aus in den Suspend. Mit dem neuen ModemManager bleibt das Modem wach und kann das System wecken, wenn ein Anruf kommt. SuspendGuardian macht noch mehr und dann genügend präzise konfiguriert werden.

Damit das problemlos funktioniert, macht Ihr folgendes:

cp ModemManager.service /etc/systemd/system/
vi /etc/systemd/system/Modemmanager.service

Die Zeile ExecStart= wird wie folgt geändert:

ExecStart=/usr/sbin/ModemManager –test-no-suspend-resume

Dann  „systemctl daemon-restart; systemctl restart ModemManager“ oder einen kurzen Reboot, falls das nicht klappt 😉

Da ich den neuen Kernel schon testen konnte, weiß ich, daß das Gerät (mit Modem im Tiefschlaf / also vor der Anpassung oben) in 8h knapp 4% Akkuladung verbraucht hat.

Ich habe dies bei meinem Pinephone natürlich schon gemacht und bin mal gespannt , wie viel Strom das Pine so in der Nacht verbrauchen wird. Das ist ein Game-Changer Feature fürs Pinephone!  Weil ab jetzt ist der Verbrauch quasi nur noch von der echten Nutzungsdauer von Apps abhängig.

 

Pinephone: Gnome Power-Buttonproblem gelöst

Posted on by

Gestern noch Extension, heute schon Downstream Patch. Naja, noch nicht ganz, aber schon eingereicht.

Pinephone: Gnome Power-Buttonproblem gelöst

Ich habe es ja schon geschrieben, das Pinephone unter Gnome läßt sich erfolgreich per Gnome Extension locken und ausschalten. Aber den Handy übliche Weg ging leider nicht, bis jetzt.

In einer nervenaufreibenden installationsschlacht, weil jedes sch*** Abhängigkeit mußte einzeln im Repo gesucht und installiert werden, was Stunden gedauert hat auf dem Pinephone, aber am Ende war alles dann sehr, sehr schneller erledigt. Mein Pinephone kann jetzt auf Druck der Powertaste gesperrt und runtergefahren werden. Damit ist ein alltägliches Mindestsicherheitsfeature von Handies erfüllt.

Da ich den Maintainer des entsprechenden Pakets gestern noch informiert habe, müßte es bald einen Downstreampatch geben für den Fedorabuild, der das dann sauber an alle Pines verteilt 🙂 Allerdings werden sollte Patche einer Reihe von Tests unterworfen, bevor sie akzeptiert werden. Ich bin da aber zuversichtlich.

Mehr dazu in Teil 6 ? der Artikelserie 🙂