Author Archives: marius

Pinephone: Daily Driver – Tag 1

Posted on by

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.

 

Coronachroniken: Der Shift

Posted on by

Liebe Maskierte,

lust auf kleines Mysterium?

Coronachroniken: Der Shift

Ich habe ja so ein Problem mit dem genauer Hinsehen. Ich weiß, ich sollte es nicht tun, aber ich kann es einfach nicht lassen. Schaut Euch mal diese Grafik an:

Ich mußte auch genau hinsehen, aber es ist interessant, wenn man es erst einmal gesehen hat, fällt es direkt ins Auge. Der kleinste Balken ist immer Sonntag, den könnt Ihr als feste Referenz nehmen. Vor dem 21.12. ist der Donnerstag der Tag mit dem höchsten Wert an Neuinfektionen, aber seit dem 21.12. ist es der Mittwoch. Ihr könnt auf dem Dashboard vom RKI nachsehen, seit März rockt der Donnerstag. Jetzt nicht mehr. Um den Aluhüten gleich den Wind aus den Segeln zu nehmen, es gibt vermutlich genug realistische Gründe, wieso das passiert ist: z.B. könnte der Rückstau in der Woche schneller abgearbeitet worden sein, so daß Meldungen, die sonst erst am Donnerstag ankamen, jetzt schon Mittwoch da sind z.b. Effizienteres Meldesystem. Das ich das aber in Anbetracht unseres Meldesystems auch für eher nicht den Grund halte, aber ich mal beim RKI nachgefragt ( auf Antwort wird gewartet ).

Eine andere spannende Frage ist diese merkwürdige Abflachung seit dem 10.2. in der blauen Neuinfiziertenkurve. Ich mache das jetzt seit letzten März, aber son Knick habe ich bei natürlichen Zahlen noch nicht gesehen. Normalerweise sind die alle abgerundet, rauf wie runter. Das wäre ja nur erklärbar, wenn die Ursache nicht natürlich wäre, also z.b. eine gleichbleibende Anzahl an Meldungen aufgrund einer gleichbleibenden Ursache, wie einer konstanten Zahl an Impfungen und daraus resultierenden konstanten Anzahl an (falschen) positiven PCR Coronainfektionstests. Wenn man sich mal dazu den blauen Verlauf im März/April ansieht, der durch nichts beeinflusst wurde und daher als natürlich gelten kann, dann sieht das doch nach einer künstlich herbeigeführten Stagnation aus, oder?

Ich glaube, bei der blauen Kurve stimmt seit Oktober nichts mehr. Kann man aber leider nur indirekt beweisen, indem man sich die Hospitalisierten (orange) und Sterbefälle (rot) als Referenz ansieht. Ich würde ja gern mal mit jemandem, der das mit der mathematisch Modellierung besser drauf hat als ich, für Oktober nach bauen. Da kommen wir bestimmt zu einem anderen Ergebnis als das RKI 😉

Pinephone: Die Sache mit der Hardwarebeschleunigung

Posted on by

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.