Pinephone: Daily Driver – Tag 1

Hallo Linuxphone Fans,

heute ein Bericht zu Neuerungen am Pinephone und die Antwort auf die Frage „Wie wars damit im Meeting zu sitzen“ 🙂

Pinephone: Daily Driver – Tag 1

Zunächst, es gibt jetzt Gnome 40 BETA für Pinephone, aber leider stützt seitdem die gnome-session häufiger ab. Ich kann das Update nicht empfehlen. Leider hängt da eine Menge an anderen Programmen dran, weshalb dies (Nicht)Update dann sehr viele andere Updates verhindert. Wenn es Euch hilft: Es stürzt zwar ab und zu ab, aber das ist nicht sooo dramatisch oft.

Die Gnome Session 40 Beta hat auch einen Vorteil, denn die 2 Min. Timeouts beim Runterfahren oder Rebooten sind weg, Jetzt hängts nur noch am Ende beim Reboot oder Shutdown Target 😀

Mit dem nächsten Systemd Update wird jetzt systemd-oomd auf dem Pinephone nicht mehr ausgeführt, weil „tada“ .. mangelnde Unterstützung 🙂 Brauchen tun wir den zur Zeit eh nicht, weil 3 GB RAM schon ganz ordentlich sind, bei den bisschen Apps die da zum Einsatz kommen.

Megapixels kommt

Megapixels ist in einer neuen Version erschienen und stützt/friert jetzt beim Foto speichern nicht mehr ab/ein. Außerdem hat Martijn Braam ein Farbkorrekturprofil hinzugefügt, so daß wieder Farbe in die Bilder reinkommt. Leider funktioniert das in der Vorschau nicht live. Da man es nicht eh nicht beeinflussen kann, spielt das auch keine Rolle. Außerdem ist der Kamerawechsel jetzt stabil möglich. Das gilt auch für die ISO und Shutter(Belichtung) Einstellungen, die zwar immer noch umständlich und zu klein, aber dafür wenigsten ohne Absturz nutzbar sind.

Megapixels hat jetzt einen eingebauten QR Scanner, der sogar funktioniert, wenn man ein Pinephone mit funktionierendem Autofocus hat, was, laut Martijn Braam, nicht jedes Pinephone hat. Die Ursache ist unbekannt, wie so vieles was diesen verbauten Chip betrifft 😉  der QR Code Scanner zeigt bislang den Inhalt nur in Megapixels ab. Ich habe mal vorsichtig angefragt, was denn eigentlich passieren sollte 😉

Als Appetitthäppchen habe ich da mal was für Euch:

22:30 Uhr – Darktable WB Korrektur – Krita mit Iain’s Denoise entrauscht

Wir hatten heute Nebel – Krita Farbsättigung – Entrauscht mit Iain’s big Denoise

22:15 Uhr Entrauscht mit Krita Iain’s big Denoise ( G’mic )

Verglichen mit einem Chip von 2010 ist das „gar nicht mal so übel“ meinte Martijn 😀

Umwerfende Bilder werden wir aber vermutlich mit dem Pinephone nie sehen werden 😉

Pinephone als Daily Driver – Tag 1

Kommen wir zur spannenden Frage, wie wars denn so tagsüber mit dem Pinephone als Begleiter?

Tja, Warm 🙂 also man merkt es in der Tasche, wenn es was getan hatte. Positiv überrascht war ich, daß Gesprächspartner nicht gemerkt haben, daß sich das Telefon gewechselt habe. Das Mikro ist auch passend laut und super im Freisprechen im Auto. Das war allerdings schon alles positive des Tages.

Phosh ist wegen Gnome-Session bei der Vorführung abgesemmelt. Naja, gnome-session riss es mit, als es den Abgang machte. Dafür war es dann sehr schnell wieder da. Für 4 h Einsatz sind 50% Akkuladung drauf gegangen, da der Leerlauf bei 1.3 – 1.5 W liegt. Das ist für ein Telefon absolutes Nogo. Da werden noch viele Devs jahre mit verbringen, bis der Linux Kernel weiß, was Energiesparend ist.

Ein Anruf schaffte es nicht zur Annahme durch den Lockscreen, vermutlich weil ein Mediaplayer Musik spielte. oh, ich habe mich übrigens geirrt, es gibt doch noch etwas positives: Die Medienkontrolle im Lockscreen funktioniert, was sehr praktisch beim Autofahren ist, da man es damit blind bedienen kann: blindes Verklicken tut niemandem weh.

Für Nachts durfte dann Android wieder dran. Mal sehen wie der nächste Testtag wird.

 

Pinephone: Die Sache mit der Hardwarebeschleunigung

Liebe Linuxphone Fans,

wir können Eurer Telefon schneller und energieeffizienter machen \o/

Pinephone: Die Sache mit der Hardwarebeschleunigung

Wie wir wissen, ist die MALI400 GPU in dem Pinephone, um es Milde auszudrücken, nicht die beste GPU. Aber sie reicht um MPV so schnell zu machen, daß FullHD Videos komplett ruckfrei laufen.

Wir brauchen als erstes die libva-v4l2-request Library:

sudo dnf -y install libva-v4l2-request

dann müssen wir das Desktopfile von MPV ändern:

Exec=env LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video0 LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0 mpv –osd-duration=3000 –fs –hwdec=vaapi-copy –vo=gpu,drm –player-operation-mode=pseudo-gui — %U

Wenn man jetzt MPV startet, dann hat man praktisch kein Frame-Drops. Bei einem 5 Minuten Video kam ich auf 17 Drops. Leider kommt das stark drauf an, welcher Codec in dem Film oder Stream, ja richtig gelesen, drin ist. Es gibt offensichtlich gut zu dekodierende Dateien und weniger gute, obwohl die alle vom gleichen Programm gebaut wurden. Aber selbst die schlechten waren ohne Verluste zu sehen.

Im Zuge des LPD 2021.1 probiere derzeit One-2-Many Streaming aus und hab dem Pine dann mal den 15 Mb/s Feed vorgesetzt. Das hat den Chip komplett überlastet 😀 Da hing nach ein paar Minuten der Videofeed 30 Sekunden hinterher, aber der Ton war nur 1-3 Sekunden hinterher. Das war überraschend. Offensichtlich lädt und Dekodiert MPV das in zwei getrennten Threads.

Firefox & Chromium

Weniger erfolgreich war ich bei Firefox und Chromium. Chromium hat zwar bessere Ergebnisse abgeliefert als Firefox, der komplett gefailed hat. Beides war aber noch keine Bestätigung, daß es überhaupt funktioniert hat. Beim Firefox fehlen neuerdings Configoptionen, die vor 6 Monaten noch gebraucht wurden. Ich habe mal den Herrn Stransky von Redhat zurate gezogen, der das bei Firefox eingebaut hat. Mal sehen was dabei rauskommt.

Pinephone: Taschenlampen App – die Zweite

Hallo Linuxphone-Fans,

ich habe da mal die Taschenlampen App etwas vereinfacht und von Eurem Phosh aufrufbar gemacht.

Pinephone: Taschenlampen App – die Zweite

Auf Github habe ich Euch die Sourcen dafür heute bereitgestellt. Ok, ok.. es ging nicht eher, ich hab es erst heute geschrieben 😉

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

Der Unterschied von dieser Version zu der Bash Version mit Sudo ist, es kommt ohne Sudo aus … und ist nicht mehr Bash, sondern C . Alles was Ihr zum Kompilieren braucht, ist das gcc Packet und das eine oder andere Develpaket. In einem Develpaket sind Strukturen, Definition und Macros gespeichert, die für die Benutzung einer Library benötigt werden. Man kann da auch andere Sachen reinschreiben, aber das führt jetzt zu weit.

Wie bauen wir die neue Taschenlampe jetzt?

Wenn wir uns das Makefile ansehen, welches hier wirklich ein Makefile ist und nicht ein File für den „make“ Befehl, ist die Sache ganz einfach:

gcc flashlight.c -o flashlight

Damit bauen wir das Binary, also die ausführbare Datei. Wenn Ihr das direkt auf Eurem Pinephone macht, wird da automatisch ein für die laufende Architektur gedachtes File erzeugt. Hier ist das „aarch64“. Wenn Ihr das spaßeshalber auf Eurem großen PC macht, und dann die Datei auf das Pine kopiert, werdet Ihr feststellen, daß es nicht funktioniert. Auf Eurem großen PC wurde es für x86_64 gebaut.

Ist das Binary fertig, setzen wir die nötigen Rechte: Hier „Jeder darf es ausführen und bei Ausführung darf es das als Root tun“. Wir erinnern uns: Rootrechte sind nötig, um die LED Helligkeit setzen zu dürfen.

chmod 755 flashlight
chmod u+s flashlight

Nun kopieren wir das Binary „flashlight“ an seinen Ausführungsort: /usr/local/bin

rm -f /usr/local/bin/flashlight
mv flashlight /usr/local/bin/

Jetzt noch die Desktopdatei ins passende Applicationsverzeichnis verschieben:

rm -f /usr/share/applications/flashlight.desktop
cp flashlight.desktop /usr/share/applications/

Wieso ist hier „cp“ im Spiel und nicht „mv“ wie beim Binary?

Vielleicht wollt Ihr ja mal ein Update machen und dann wär es doch Schade, wenn das Desktopfile weg wäre. Das Binary baut Ihr ja jedes mal neu, ob das für einen zweiten Durchlauf noch vorhanden ist, spielt keine Rolle. Das Desktopfile wäre dann weg 😉

Wieso ist das dem Sudo-Bash Konstrukt überlegen?

Für das korrekte Sudofile muß man wissen, wie der Username des ausführenden Benutzers lautet. Seine UID würde vielleicht auch noch gehen. Außerdem mußten wir erstmal die sudoers-Datei ändern, damit die Anweisung ausgeführt wurde. Das fällt alles komplett weg.

Damit das Programm so auf jeder Distribution einsetzbar, völlig egal von den Umständen.

Gibt es Sicherheitsbedenken?

Die gibt es immer, es ist ein SUID Programm. Nun ist in dem Programm nichts drin, was gefährlich ist, solange die echten Betriebssystem Libs benutzt werden. Schafft es ein Angreifer, dem Befehl eine eigene Kopie einer benutzten System-Lib unterzujubeln, und dafür gibt es Möglichkeiten, könnte er die Funktionsaufrüfe nutzen und einfach irgendwas anderes machen.

Ich denke aber nicht, daß das mit diesem Build möglich ist. Falls Ihr Verbesserungen habt, schickt einen Pull-Request in Github-Repo oder lasst einen Kommentar da. C ist nicht gerade mein Steckenpferd und die GCC Options schon gar nicht 😉

Wann kommt das endlich in den Fedora Build rein?

Überraschung !… Torbuntu baut schon dran 😀