Pinephone: Judgement Day!

In den letzten Tagen haben wir das Pinephone zusammen aufgebaut, es gewartet, mit Ihm gespielt, ja so angefreundet. Heute aber kommt der Terminator, denn es ist …

Pinephone: Judgement Day!

Wir haben jetzt den 4. Advent… ok, Ihr aber nicht mehr.. und noch kann man mit dem Pinephone nicht das tun, was der Name insistiert: Telefonieren. Ok, zumindest unter Fedora kann man es nicht, weswegen ja auch noch die Manjaro Community Edition auf der internen Speicherkarte ist.

Was geht denn so alles nicht mit dem Pinephone und wo hakt es gewaltig?

Gestern machte ich mich bewaffnet mit meinem neuen „Telefon“ auf den Weg um das GPS in freier Wildbahn zu testen. Leider kam ich nur bis zur anderen Straßenseite, dann war die Grenze des Wlan überschritten und die Gnome-Maps Anwendung streikte knallhart. Merke: Ohne I-NET keine Positionsupdates – von Offlinekarten & Cachen keine Spur.

Ok, ein Smartphone sollte ja i.d.R. Mobilfunk dabei haben, aber was machen die Leute, die damit von einer Nordseeinsel zur anderen Insel navigieren wollen? Antwort: In die Röhre schauen!

Viel Spaß hätten Sie mit der zickigen kleinen App auch nicht, denn die Schrift für die Straßen wird winzig angezeigt, keine Chance da im Auto während der Fahrt etwas zu lesen. Immerhin Routenplanen geht, aber auf die Idee, den GPS Standort als Ausgangsort für eine Route zu benutzen oder auch nur anzubieten: Fehlanzeige. Es würde sowieso nicht nutzen, bedienen lässt sich die App während der Fahrt eh nicht, die Buttons sind viel zu klein dafür, wenn sie denn überhaupt auf einen Druck reagieren. Wäre die App von Google, dann wären die heute ein Subunternehmen von Microsoft oder Apple.

Fehlender DPI Ausgleich

Das Hauptproblem hier ist der fehlende DPI Skaler in den Bildschirmeinstellungen. Der würde Appanwendungen größenmäßig verdoppeln, was der Sache entgegen käme, aber aus irgendeinem Grund (vermutlich Display zu klein .. muhahahar .. urgs 🙁 ) nicht vorhanden ist.

Foto: Surface Pro 4 Fedora 32 Gnome

Wenn ich mein 3k Tablet nehme, kann ich dort 100%, 200% und 300% auswählen. Das müßte im Pine eigentlich nur mal aktiviert werden. Kann eigentlich nicht so schwer sein. Phosh setzt an genau dieser Stelle an, da es dort quasi permanent aktiviert ist. Man kann es dort zum Ausgleich dafür aber nicht abschalten 😉 Mir ist gerade danach, der Aufforderung der Musik in meinen Kopfhörern zu folgen und das A-Team zu Hilfe zu rufen.

Das Gnome-Team

Ich habe ja erwähnt, daß ich 16 offene Bugs bei Gnome habe, einige beziehen sich darunter auch auf Maps. Da meinte doch ein Witzbold, daß man da den Drei-Finger-Swipe benutzen könnte um aus der Fullscreen Anwendung auf den Aktivitätenscreen umzuschalten. Der Mann hatte offenkundig noch kein Telefon mit Gnome in der Hand 😀 Das geht natürlich technisch schon, weil die Swipes theoretisch erkannt werden, aber so rein physikalisch gibt es da das Problem 3 Finger auf den Bildschirm zu bekommen und die dann auch noch auf einanderzu zu bewegen. Die ersten zehn Versuche haben nicht funktioniert. Auf dem Tablet ist das platzmäßig natürlich kein Problem. Jetzt kommt aber verschärfend noch hinzu, daß Maps ja auch auf Fingergesten reagiert 😉 Es ist genauso schlimm, wie Ihr es Euch gerade ausmalt.

Tagesform

Im Gnome-Team gibt es echt Leute die mitdenken und welche, naja, reden wir nicht drüber. Die Anzahl der vernüftigen Teammitglieder überwiegt zum Glück. Am 21.12. kam Bewegung in einige Bugs bei Gnome. Z.b. stellte sich herraus, daß die seit einem Jahr um das Problem der falsch positionierten Notificationsfensteres wissen, da auch jede Menge Patche an „mutter“ gemacht haben, es aber nicht zum Erfolg geführt hat. Was ist eigentlich so schwer daran einen Rechenfehler zu beheben, weil witzigerweise die Klicks auf dem Bildschirm an den korrekten Stellen erkannt und nur die grafischen Inhalte außerhalb vom Screen gemalt werden:

Das die ganzen Gnome App-Windows so Ihr Eigenleben führen, wissen wir ja. Starten die Fenster aus irgendeinem völlig unerfindlichen Grund mit Fenstern, die BREITER sind als der Bildschirm breit ist, reagieren die nicht auf Maximieren. Minimieren geht, aber Maximieren wird ignoriert. Das zu erwartende Verhalten wäre übrigens, kleiner zu werden und sich maximal dem Fenster anzupassen. Dann gibt noch die Appfenster, die darauf reagieren, aber einen Rand lassen! Was an „Maximieren“ ist eigentlich so schwer zu verstehen???

Von der Tagesform abhängig scheint auch der Inhalt zu sein. Das Gnome-Control-Center aka „Einstellungen“ hat einen an sich coolen weg mit Platzproblemen umzugehen. Es zeigt einfach nur die Auswahliste der Sektionen an und dann hinter den Namen einen kleinen Pfeil „>“, drückt man drauf, wird der Inhalt des Fensters eine „Etage“ nach Links geschoben, so daß man die Kontrollen benutzen kann. Theoretisch. Praktisch kommt es vor, daß das Fenster mal so, oder zweigeteilt erscheint. Dann sind links die Sektionsnamen und rechts die Kontrollen.

„..zu erwartendes Verhalten..“

Apropos „zu erwartendes Verhalten“, da meinte doch einer dazu, daß die Hotcorner links oben ( Activities ) zu recht nicht gehen würde, weil eine App im Fullscreen wäre. Blöd nur, daß gar nicht die Hotcorner Funktion gemeint war, sondern das Activities Button links oben in der Ecke selbst, das man sich mit dem Links->Rechts Swipe aus einer Fullscreenapp reinswipen kann, dann aber nicht funktioniert und jetzt kommts, mit der Begründung, „das wäre ja absichtlich so“. Ihr vermutet richtig, es war der gleiche Witzbold. Ich habe nahegelegt, doch die Erwartungshaltung zu ändern, weil die Fullscreenapp in dem Moment, wo man das Activities-Button zu sehen bekommt, eh nicht mehr zu sehen ist, sondern der Dock, den man reingeswipt hat. Leider keine Reaktion bekannt.

Statt sich mit Bugs auseinander zu setzen, wird gern mal an der Form moniert. Ich gebe da alle relevanten Infos an, wenn da mal bei „onboard“ die Anführungszeichen fehlen, wird gleich auf stur gestellt. ( Genau, Der Herr 😉 ) Ich muß allerdings auch gestehen, nach den ersten Bugs, hatte ich echt keinen Bock mehr deren Bugtrackerwahl ( Gitlab ) auszubaden, wo man sich erst das Projekt ( wenn man es denn kennt, was ich nicht zwangsläufig weiß ) auswählt und dann erst einen Bugreport anklicken kann. Wenn man Bugtracker kennt, sind da als erstes alle bekannten Komponenten in einer Auswahlbox und dann legt man mit Auswahl des OS, Architektur usw. los. Eine Singlepageanwendung quasi, nicht so bei Gitlab.

Wenn man es schon mehr zu seinem eigenen Projekt weiß als die Bugreporter, dann sollte man das einfach dem Projekt zuweisen und loslegen. Meine Meinung.

Die Ursache für die ganzen Bugs war übrigens die Maximierenfunktion meines Scripts, mit der alle neugestarteten Anwendungen handygerecht groß gemacht werden, weil sonst in der Regel unbrauchbar. Komisch ist nur, daß es bei Nicht-Gnome-Fenstern keine Probleme damit gab 😉

Zurück zum Pinephonetest in freier Wildbahn

Was passiert mit zu sensitiven Touchgeräten? Weiß man nicht, weil die Batterie auf mysteriöse Weise schnell erschöpft ist. Woher ich das weiß? Ich habe meins rechtzeitig aus der Hosentasche gezogen.

Wie Ihr ja wisst, habe ich dem Power-Button beigebogen, das Handy in den Stand-By zu schicken. Das dumme an Powerbutton mit rausstehendem Knopf ist, das sie beim Gehen von alleine gedrückt werden. Das Ende vom Lied ist, die starten dann, landen im Lockscreen und … bleiben da 🙁

Denn das Display ist so sensitiv, was zwar gut bei der gewollten Eingabe, aber sehr schlecht in der Hosentasche ist. Nach 20 Sekunden habe ich aufgegeben auf DELETE zudrücken  und einfach Login geklickt, damit das Eingabefeld für das Passwort wieder frei wird. Das ist natürlich nicht das einzige Problem das daraus resultiert. Weil alle paar Sekunden eine Eingabe erkannt wird, geht der Lockscreen nicht wieder aus. Der Bildschirm bleibt an und der zieht so 0.5 W zu den 1.5 W, die im Lockscreen ohnehin verbraucht werden.

So kann das Pinephone leider nicht ernsthaft bleiben, weil es unbrauchbar ist. Auch der Einsatz des extra für mobile Endgeräte entwickelten Phosh Desktops, hilft nur bedingt weiter. Auch da sind Schaltflächen zu klein, Fenster zu breit und frech wie oskar kann man sich mit Phosh 0.6 nicht mal mehr abmelden um einen anderen Desktop zu starten, Phosh 0.7 crasht gleich beim Start und 0.7.1 war noch nicht verfügbar.

„Housten, haben wir irgendwas das wie gewollt funktioniert?“

Ich habe vorhin entspannt „Battle of Wesnoth“ gespielt, bis der Akku „plötzlich“ leer war. Die meiste Zeit habe ich auf „Zug beenden“ gehämmert, aber naja 😀

Wenn man mal von dem Kram oben absieht, dem viel zu hohen Stromverbrauch und dem Umstand, daß ich immer noch nicht mit Fedora telefonieren kann, können wir auf das Jahr 2021 hoffen. Es kann eigentlich nur besser werden.

Also dann: Wir sehen uns in 2021 😀 Guten Rutsch Euch allen!

Pinephone: Ein Schritt in Richtung Normalität

Heute, am zweiten Weihnachtstag, bringen wir nochmal etwas Normalität auf das Pinephone. Normal ist da nichts, aber das sollte uns nicht aufhalten 🙂

Pinephone: Ein Schritt in Richtung Normalität

Was fehlte denn bislang? Wir haben zwar Video, aber nur per MPV und Konserve. Da kommt jetzt Youtube gerade recht, wenn da nicht der Browser im Weg wäre 🙁 Der aktuelle Chromium 87x für ARM64 hat leider ein paar gravierende Bugs im Rendering und Umgang mit GPU, weswegen man viele Texte nicht sieht. Das hatte ich ja schon erwähnt: Chromium: Probleme Texte zu rendern kein Pinephoneproblem

Was tun?

Einfach den 85er Chromium benutzen, der hat die Bugs nämlich nicht. Solange man damit nur Youtube und eine klitze kleine andere Überraschung macht, ist das Sicherheitstechnisch kein Problem.

sudo dnf -y downgrade https://kojipkgs.fedoraproject.org//packages/chromium/85.0.4183.121/2.fc34/aarch64/chromium-common-85.0.4183.121-2.fc34.aarch64.rpm https://kojipkgs.fedoraproject.org//packages/chromium/85.0.4183.121/2.fc34/aarch64/chromium-85.0.4183.121-2.fc34.aarch64.rpm

Damit ziehen wir uns die alte Version vom Chromium für Fedora 34 rein.

Warum die 85? Kommt gleich 🙂

Wie man sehen kann, funktioniert Youtube damit und das sehr viel besser als Firefox, die Werbung stört natürlich auch hier, aber da kann man nicht viel machen, weil FreeTube nicht für ARM gebaut wird afaik.

Ein paar GPU Renderblips zeigt der Chromium dann, aber das ist verschmerzbar, weil es nur beim Aufbau der UI vorkommt, beim Playback war es nicht zu beobachten.

Jetzt kommt das Problem damit: Chromium ist extrem folgend bei DPI-Scaling, das wir aber brauchen um das Gnome-UI so groß zu bekommen, daß man es auf dem Pine mit Fingern bedienen kann. D.b. in der Praxis, wenn wir das Scaling in Gnome-Tweaks auf 1,5+ stellen, dann paßt der Inhalt von Chromium nicht mehr auf dem Screen. Das ist eigentlich unlogisch, weil das nur die UI also Gnome-Shell und Windowmanager betreffen sollte, aber keine Inhalte, aber Chromium macht das dann auch mit seinem Inhalt.

Ich verurteile das nicht, weil es kein echtes Fehlverhalten ist, aber hilfreich war das auch nicht, weil einige Steuerelemente der UI ( hier im Bild von Firefox illustriert, der hat das gleiche Problem ) nicht erreichbar sind, weil es abartig groß vergrößert wurde ohne einen Sanitycheck einzubauen, ob die Elemente dann überhaupt noch in den Bildschirm passen, was sie bei Chromium dann nicht mehr tun.

Jitsi Meet

Hier also der Kompromiss: Wir drehen die Größe der Fonts im Tweaktool rauf, dafür die DPI-Skalierung runter, zwischen 1 und 1,25. Damit kann man im Portraymode Chromium so starten, daß alles auf den Bildschirm paßt.

Das führt dann zum gewünschten Ergebnis: Jitsi Meet funktioniert jetzt mit Screensharing und Ton \o/

Allerdings werdet Ihr da nicht froh werden, denn Chromium verbrennt da jetzt ungelogen die gesamte CPU Leistung von 4 Kernen. Deswegen knackt der Ton auch etwas, es laggt in der App, was Video und Ton betrifft, die Gnome-Oberfläche ist nicht direkt eingefroren, aber langsam. Der CPU verbrennt so 3.67W/s, so daß man der Akkuladung beim Entladen live zusehen kann 🙂

Netflix geht damit leider nicht, weil für ARM das Widevine DRM Modul nicht verfügbar ist, da es nicht für Chrome kompiliert wurde und so nicht integriert werden kann. ( Nette Anleitung bei Chip, wie man das opportunistisch organisiert 😉 ). Merke: Kein Netflix für Pinephones 🙁

LollyPop Update

Viel bessere Nachrichten gibt es von der Lollypop-Front: das Update 1.4.7 ist da und behebt alle Bugs, die ich bislang finden konnte \o/ Das sieht dann so wie rechts aus, wenn man die DPI-Skalierung wieder etwas anhebt ( 2,00 ).

Damit läßt sich richtig gut auf dem Pinephone arbeiten und ich sage das nicht leichtfertig. Es ist hier definitiv viel sinnvoller als QMMP. Es scrollt sich herrlich, wenn man an den trägen Nautilus denkt. Bis man aus dem einen Klick rausgeholt hat, keine Ahnung wer das bei wieder verbrochen hat 😀

Wer meinem Guide zu Beginn gefolgt ist, der hat Lollypop jetzt bereits drauf und muß nur kurz das Update einspielen. Jetzt müssten nur die Kopfhörer gut funktionieren und die Sache wäre perfekt 🙂

 

Pinephone: Judgement Day!

 

 

Pinephone: wie man ohne Phosh ein Handyfeeling simuliert

Was haben Pinephone Apps und Android Apps nicht gemeinsam? Genau, jede Pinephone aka Linuxapp macht ihr eigenes Fenster in ihrer Lieblingsgröße auf. Das ändern wir heute.

Pinephone: wie man ohne Phosh ein Handyfeeling simuliert

Um das machen zu können, brauchen wir ein dauerhaft laufendes Programm. Idealerweise würde so etwas der Windowmanager übernehmen, der läuft eh, aber da es Gnome ist, naja, nicht so schnell umsetzbar. Also machen wir das mit einem Script: windowmaximixerwatch

#!/bin/bash

rm -f /tmp/liste
i="0"
while [ $i -lt 1 ];
do 
	windowmaximizer > /dev/null
	sleep 1
	RC=$(ps auxf| grep -c gnome-shell)
	if [ $RC -eq 0 ]; then 
		i=1
	fi
done

Diese Datei wird nach /home/pine/.local/bin/windowmaximizerwatch geschrieben

„Das macht ja gar nicht so viel“ Stimmt, aber das ist ja auch nur ein Teil davon. Wie man leicht erkennen kann, ist das eine Programmschleife, die nur dann abbricht, wenn kein Gnome-Shell-Prozess (mehr) vorhanden ist.

Das Programm „windowmaximizer“ ist auch nur wieder ein Shellscript, das die ganze Arbeit macht:

#!/bin/bash

#1 
ISONBOARDOPEN=$(wmctrl -l | grep -c Onboard)

#2 
RESOLUTION=$(xdpyinfo | grep dimens | awk '{print $2;}')
X=$( echo $RESOLUTION | awk -F "x" '{print $1;}')
Y=$( echo $RESOLUTION | awk -F "x" '{print $2;}')

#3
ORIENTATION="landscape"
if [ $Y -gt $X ]; then 
        ORIENTATION="portray";
fi

#4 
LASTORIENTATION=$(cat /tmp/display.orientation.last);
if [ "$LASTORIENTATION" != "$ORIENTATION" ]; then

        # REMOVE OLD IDs as all needs to get maxed newly, because we had a layout orientation switch
        rm -f /tmp/liste
fi

echo "$ORIENTATION" > /tmp/display.orientation.last;

#5 create new /tmp/liste if missing:

touch /tmp/liste

# place Onboard window at the correct position and define variables for wmctrl cmds:

if [ "$ORIENTATION" == "portray" ]; then

        wmctrl -l | grep Onboard | awk '{print "echo "$1";wmctrl -i -r "$1" -e 2,0,1170,720,270";}' | bash
        TOP=41
        WIDTH=720
        if [ $ISONBOARDOPEN -eq 0 ]; then 
                HEIGHT=1440
        else 
                HEIGHT=1130
        fi

else
        wmctrl -l | grep Onboard | awk '{print "echo "$1";wmctrl -i -r "$1" -e 2,0,450,1440,270";}' | bash
        TOP=41
        WIDTH=1440
        if [ $ISONBOARDOPEN -eq 0 ]; then 
                HEIGHT=720
        else 
                HEIGHT=410
        fi
fi 

#6 now ALL windows WITHOUT Onboard, that are still unprocessed ( not in our brain file ), get processed. This is needed as resizing causes a lot of pain to the eye, as it flickers, even if it's not needed.

LISTE=$(wmctrl -l | grep -v Onboard | awk '{print $1;}')

for id in $LISTE
do 
        echo "processing $id";
        RC=$(grep -c $id /tmp/liste)
        if [ $RC -eq 0 ]; then 
                echo "resizing $id"
                wmctrl -i -r "$id" -e 5,0,$TOP,$WIDTH,$HEIGHT
                wmctrl -i -r "$id" -b toggle,maximized_vert,maximized_horz
                wmctrl -i -r "$id" -e 5,0,$TOP,$WIDTH,$HEIGHT
#               wmctrl -i -r "$id" -b remove,fullscreen
                echo $id >> /tmp/liste
        fi
done

#7
# Now we check, if all ids in your brain file are still open windows. Thats needed, because same windows, get the same id, when they are closed and repopend.
# if they are closed we need to remove the id, because we need to reposition them again on next open.

LISTE=$(cat /tmp/liste)
for id in $LISTE
do

        RC=$(wmctrl -l |grep -c $id)
        if [ $RC -eq 0 ]; then
                # Entferne Windows die weg sind!

                echo "remove id $id";

                grep -v $id /tmp/liste > /tmp/liste2;
                rm -f /tmp/liste;
                mv /tmp/liste2 /tmp/liste;
        fi 
done

Diese Datei wird nach /home/pine/.local/bin/windowmaximizer geschrieben.

  1. wir stellen erstmal fest, ob das Onboard OSK läuft. Das ist wichtig für die Berechnung der Fenstergröße, auf die die Apps gezogen werden müssen.
  2. xdpyinfo teilt uns die Bildschirmauflösung und jede Menge anderen Kram mit.
  3. Anhand der ermittelten X/Y Koordinaten legen wir fest, ob wir im Landscapemode ( 1440×720 ) oder Portraymode ( 720×1440 ) arbeiten.
  4. Wenn sich die Orientierung innerhalb des letzten Aufrufes geändert hat, löschen wir die gesicherten FensterIDs, so daß alle Fenster auf die neuen Gegebenheiten umgeändert werden.
  5. nun repositionieren wir das Onboard OSK passend zur Orientierung an die richtige Stelle und berechnen gleich noch die Variablen für die Fensterhöhe und -breite.
  6. nun werden alle Fenster, deren FensterIDs wir noch nicht bearbeitet hatten, was in einer Datei gespeichert wird, auf Position gebracht. Das sind die, die in der letzten Sekunde noch nicht da waren.
  7. Natürlich muß man auch mal aufräumen, was in diesem Fall meint, daß alle FensterIDs aus der Speicherung entfernt werden, die nicht mehr präsent sind. Normalerweise würde man ja annehmen, daß FensterIDs fortlaufend sind, aber nicht bei uns, da werden die FensterIDs wiederverwendet. Tja.

Das funktioniert ganz gut, von Gnome selbst mal abgesehen. Alles was wir jetzt noch machen müssen, ist dem ganzen ein Desktopfile zu erstellen, damit es in der Appübersicht auftaucht:

[Desktop Entry]
Version=1.0
Name=WindowMaximizer
Name[de_DE]=WindowMaximizer
Exec=windowmaximizerwatch
#Terminal=false
Type=Application
StartupNotify=true
#Icon=cs-login
Icon=/usr/share/icons/Mint-X/apps/96/cs-login.svg
MimeType=x-content/unix-software
Categories=Network;
Keywords=web;internet;
X-Desktop-File-Install-Version=0.23

Diese Datei wird nach /usr/share/applications/windowmaximizer.desktop geschrieben.

Wenn alle Shellscripte mit chmod 755 versehen wurden, kann es losgehen. Ich rate dazu ein anderes Icon zu benutzen, da müßt Ihr allerdings selbst sehen, welches Ihr nehmen wollt.

Mit dem Gnome-Tweak-Tools ( Optimierungen ) kann man das Script als App im Startmenü platzieren und so sollte es beim nächsten Start des Desktops automatisch mitstarten. Wenn es das nicht tut, einfach von Hand selbst starten.

Ab nun werden alle-gnome Fenster maximiert und selbst bei Gnome-Fenstern klappt das gelegentlich ( die haben so eine Art Tagesform ). Wer das ganze verbessern will, kann noch eine APP Datenbank aufbauen, aus der z.b. festgelegt wird, ob eine Anwendung in Fullscreen gehen soll, oder nicht. Ist nur so ein Gedanke.. an einen weiteren Bugreport bei Gnome 😉 Natürlich habe ich das schon ausprobiert 😀

In 3 Tagen sehen wir uns wieder. Achtet auf die täglichen kleinen Pine Updates, die kommen alle außer der Reihe rein. Öfters Reinschauen oder gleich den RSS-Feed abonnieren.

 

Pinephone: Ein Schritt in Richtung Normalität

Pinephone: Wie man schwer erreichbare Apps konfiguriert

Auf dem Pinephone läuft Linux, soweit so gut. Daß bedeutet auch, daß wir echt coole Sachen mit dem Pinephone machen können 🙂

Pinephone: Wie man schwer erreichbare Apps konfiguriert

Wenn Ihr meiner Philosophie folgt, habt Ihr Gnome auf dem Handy laufen. Was wäre, wenn Ihr dieses Gnome, auf Euren PC benutzen würdet? 😀 Ich habe da zwei Ansätze für Euch. Beide vereint, daß der Bildaufbau ein bisschen langweilig ist, weil das Pinephone nicht die schnellste CPU hat.

Das Display per SSH exportieren

Dafür müssen wir den SSH Server umkonfigurieren. Dazu muß man sich als root-Benutzer auf dem Pine anmelden, entweder Ihr macht das SSH oder Ihr quält Euch durch die Toucheingabe ( nicht zu empfehlen ).

Eure /etc/ssh/sshd_config sollte so aussehen:

Include /etc/ssh/sshd_config.d/*.conf
PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
X11Forwarding yes
PermitTunnel yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Dann Abspeichern der Änderungen und Neustart des Servers: systemctl restart sshd

Achtung: jetzt unbedingt Testen, ob Ihr noch einloggen könnt, sonst wird das unschön 😉 Wenn es Probleme gibt, die Änderungen einfach auskommentieren ( „#“ vor die Option schreiben )

Jetzt könnt Ihr per „ssh -Y -C pine@pine.ip“ ( Eure IP in Lan benutzen ) auf Euer handy einloggen und einfach eine Anwendung starten. Das sogenannte Display wird dann von SSH so umgebogen, daß es die Ausgabe auf Eurem PC/Laptop/Tablet oder anderem Telefon rauskommt 😉

Diese Methode ist für „schnell mal ebend“ geeignet.

RDP auf das Pinephone

Ein anderes Kaliber von mit dem Pinephone arbeiten bekommt wir über die Remote-Desktop-Schiene rein.

Damit bekommt man den Gnomedesktop auf den heimischen PC. Es sei aber gleich gesagt, für schnelles Arbeiten ist das nichts, weil der Bildaufbau langsam ist. Dafür kommt man echt an jede Ecke, jedes Icon und jede Einstellung dran.

Menüs und Optionen

Zur Vorbereitung müssen wir da erst einmal den XRDP Server installieren. Also auch hier wieder root werden und eingeben:

dnf install -y xrdp
sytemctl start xrdp
sytemctl enable xrdp
systemctl stop firewalld

Das letzte Kommando muß man erklären:

Ähm …., es ist unerklärbar. Beschönigen kann man nichts, der Firewall-Server hat ne Macke. Selbst wenn man RDP durchlässt, kommt es nicht an. Da hilft leider nur ausschalten. Aber: ab der Sekunde funktioniert dann auch endlich KDE-Connect korrekt, die DLNA Freigaben Eures Handies usw. . Ich bin zwar ein Sicherheitsfanatiker, aber echte Nachteile hat das nicht. Man kommt von außen eh nur an die Ports, an die man kommen muß, um die gewünschte Funktion auszuführen, dies könnte eine Firewall ohnehin kaum sinnvoll beschränken. Außerdem kann man sich noch eine klassische Iptables-Firewall aufbauen, falls ein Schutzinteresse besteht. Das hatte ich ja eh vor.

Hinweis: Im Mobilbetrieb, also außerhalb Eures Lans, solltet Ihr die Firewall wieder einschalten! Da muß schliesslich keiner auf Eurer Handy zugreifen können, zumal er gar nicht weiß, welche IP das gerade hat.

Kamera per RDP

ACHTUNG:

Ihr müßt ausgeloggt sein am Handy, also den Unlooker vom Handy sehen, sonst kommt Ihr als „pine“ Benutzer nicht rein. Als Root geht das, weil das eine andere Session ist.

Da man alle Apps per RDP starten kann, wobei es auch Einschränkungen gibt, weil der PolicyKit-Server nicht der hellste Stern am Himmel ist ( „CPU-Freq Problem“ ), kann man natürlich auch mit dem Firefox arbeiten oder seine Emails sichten ( diesmal in lesbarer Größe 😉 ).

Auf dem Desktop-PC brauch Ihr Remmina oder xFreeRDP um Euch dann auf Eurer Handy zu verbinden. Da ein Login via RDP ein lokaler Login ist, kann man sich auch als ROOT anmelden. So sieht das dann in Remmina aus

Natürlich könnt Ihr den XRDP auch nur dann starten, wenn Ihr den wirklich braucht, aber könnte ziemlich lästig werden.

Wir sehen uns dann beim nächsten Teil der Pinephone Serie.

Pinephone: wie man ohne Phosh ein Handyfeeling simuliert

Pinephone: nicht glib2 updaten

Kleine Warnung von der Pinephonefront:

Pinephone: nicht glib2 updaten

Frisch aus der Rawhidehölle von Fedora:

Just another heads up for folks. 

The glib2-2.67.1 update (in the rawhide thats composing right now) seems
to cause gdm to crash here. Downgrading to 2.67.0 everything is working
again.

I've filed:
https://gitlab.gnome.org/GNOME/glib/-/issues/2273
on it. 

Rawhide users may want to exclude it or gather more information for the
above bug. :) 

kevin

GDM wird auf dem Pinephone zwar nicht benutzt, aber andere Programme aus dem Gnomeumfeld werden diese Lib auch benutzen.

Am einfachsten schließt man die glib2 vorläufig von den Updates aus:

sudo echo „exclude=glib2“ >> /etc/dnf/dnf.conf

alternativ beim nächsten Updatemit -x ausblenden: „dns -x glib2 update“ .

 

Fedora: nss Update 3.59 ohne SHA-1 Sperre gepushed

Kleines Follow-Up zu diesem Artikel:

NSS 3.59 bricht mit SHA-1: Firefox Addons betroffen

Fedora: nss Update 3.59 ohne SHA-1 Sperre gepushed

Das Fedora Team hat die SHA-1 Sperre vorläufig aus dem Paket nss zurück genommen und ins Stable Repo gepusht, damit Firefox nicht gleich zusammenbricht. Damit könnt Ihr jetzt wieder bedenkenlos die Pakete updaten.

Früher oder später wird das aber scharf geschaltet werden. Mal sehen wann Mozilla seine Entwickler mit sha-256 beglücken wird.

Chromium: Probleme Texte zu rendern kein Pinephoneproblem

Ihr habt Chromium auf dem Pinephone installiert und Euch gewundert, wieso die Texte nicht angezeigt wurden?

Chromium: Probleme Texte zu rendern kein Pinephoneproblem

Tja, ich auch 🙂  Aber, es stellt sich raus, es ist ein Pinephone unabhängiges Problem. Selbst der Chromiummaintainer weiß nicht wieso es passiert. Es scheint eine Kombi aus Libc und Libva zu sein. Libva? Ja, die macht so hardwarebeschleunigtes Video auf VA API Basis.

„Libva is a library providing the VA API video acceleration API.“

Macht irgendwie Sinn, daß, wenn man schnell Texte rendern will, dafür die GPU verwenden will. Mir fiel dazu bei der ersten Analyse vor einigen Wochen auf, daß Chromium darüber meckert, daß er die libva nicht mehr ansprechen kann. Das es dem Maintainer erst jetzt auffällt, daß sein Compilat keine Texte mehr rendert, ist bestenfalls merkwürdig.

Aber seid versichert, jetzt werden wir auf dem Pinephone dann auch einen schnellen Browser haben, der bei Jitsi Meet Konferenzen nicht den Prozessor schmilzt 😉

Pinephone: Der Spiele Guide

Heute wollen wir mit dem Pinephone ein paar Spiele spielen. Wir schauen was geht, was nicht geht, und was gehen könnte.

Pinephone: Der Spiele Guide

Für diese Aktion empfehle ich den Landscapemode, also horizontale Ausrichtung des Display, wie auf dem Desktop. Dazu sollte man auch die Wayland Gnomesession auswählen, also nicht X11, da unter Wayland die Touchbedienung auch aktiv in die Programm übergeht, wenn es denn funktioniert.

Mir fangen mal mit einem negativ Beispiel an:

0AD

0AD kommt nicht über diesen Bildschirm hinaus.

Auch wenn 0AD das Vorzeigeprojekt ist, startet es zwar sauber und könnte auch 3D auf der Mali400 GPU vom Pine fahren, aber leider, schaltete es irgendwie die Touchkontrollen aus. D.b. es reagiert nicht auf Klicks und auch die Gnomegesten  zum Wechsel in die Aktivitätenübersicht sind abgeschaltet.

Unter Wayland konnte cih dem Spiel zwei Klicks entlocken, bevor Touch wieder zusammen bracht. So ganz funktional ist es daher leider nicht 🙁

Battle for Wesnoth

Ganz anders kommt allerdings Battle for Wesnoth daher. Das rundenbasierte Strategiespiel funktioniert Ad-Hoc mit allen Touchfunktionen. Zugegeben die Buttons sind leider nicht DPI skaliert, aber es funktioniert zufriedenstellend. Da allerdings das Spiel auf der GPU arbeitet, war auf dem Pine leider kein Screenshot in Vollbild machbar, daher muß ich Euch leider mit einem kleineren Exemplar befriedigen:

Battle for Wesnoth in der Aktivitäten-Übersicht

Das Spiel selbst ist Fullscreen, aber wie Ihr selbst seht, sind die Buttons etwas klein geraten. Noch etwas, so ganz reaktiv ist das Spiel nicht, was die Buttons betrifft, z.B. „Zug beenden“ unten rechts. Da muß man Doppelklickartig auf den Screen einschlagen 😉

Die Spielführung ist erschreckend gut auf Touch abgestimmt. Weniger erfreulich ist der Stromverbrauch des Pine. Eine halbe Stunde Spielspaß kosten Euch locker 20% Akkuladung 🙁

Supertuxkart

Als ich gerade SuperTuxKart testen wollte, brach gerade das Rawhideserversystem zusammen. Daher müssen wir jetzt leider schauen, ob die Fedora 33 Version aus dem Stable Build funktioniert 🙂 Praktischerweise sind alle Abhängigkeiten für das Paket bereits geladen und vorhanden.

SuperTuxkart startet etwas sehr langweilig und moniert gleich zu Beginn, daß wohl der OpenGL ES 3 Treiber veraltet wäre, es würde jetzt ohne GPU laufen wollen. Damit scheidet es leider als eins der TOP Spiele vom Pine aus 🙁

Natürlich wurde es trotz dessen angespielt 🙂

Ja, es kommt mit Lenkrad 😀

Komischerweise wollte es nicht im Fullscreenmodus starten… hmm.. Leider kann die Mali400-GPU kein OpenGL ES 3, damit wird die Spiel wohl nie funktionieren.

Auf einem Libre M5 für 799 $US läuft das alles flüssig, weil vernünftigen SOC verbaut mit vernünftiger moderner GPU.

Widelands

Tja, also Widelands (Die Siedler 2) failed mal total. Da funktioniert nicht mal das Startmenü zum Auswählen der Kampagnen.

Swell-Foop u.ä.

Hier ein Foto vom Desktop, sieht aber auf dem Pine genauso aus.

Die ganzen Gnome Games für den Desktop funktionieren auch auf dem Pine ohne „größere“ Probleme. Es wird nur komisch, wenn die Fenster größer werden. Spielt man z.B. Swell-Foop  mit der großen Karte, paßt die nicht auf den Screen, weswegen das Spiel dann unlösbar wird. Wie man als Programm, ein Fenster größer als der Bildschirm öffnet, ist mir ein Rätsel. Das müßte eigentlich failen.

Chess

Ich habe noch nie, nie!, so leicht gegen einen Computer im Schach gewonnen. Der wäre vermutlich auch auf den Schäferzug reingefallen, wenn mir der noch einfallen würde 😉

World of Warcraft

Also da muß ich Euch enttäuschen, die CPU hat a) die falsche Architektur  und b) die GPU ist dafür zu schwach, leider 😀

Fazit

Wenn also Spiele, dann eher ohne GPU. Das schränkt die Auswahl dann zwar ein, ist aber kein Beinbruch. Angry Birds wäre ja mal was gewesen. Das hätte man auch per Chromium als WebApp versuchen können. Da Chromium aber zu blöd ist ohne OpenGL3 nicht mal Texte auf einer Seite schreiben zu können, fällt das leider auch weg.

Wenn man es mal realistisch sieht, funktioniert das Pine zum Spielen tatsächlich, wenn man Abstriche akzeptieren kann. Natürlich fehlen die Knallerapps um das Telefon für Mobile Gamer auch nur ansatzweise interessant zu machen. Wenn mehr Apps die GPU unterstützen würden, sähe das vielleicht anders aus.

Mal sehen was im nächsten Bericht zum Pinephone drin ist. Telefonieren kann ich bislang damit unter Fedora nicht 😉

Pinephone: Wie man schwer erreichbare Apps konfiguriert