Commit Graph
8 Commits
Author SHA1 Message Date
StefanandClaude Opus 5 ab847cc46f S1: vorhandene Shells der Reihe nach durchprobieren
KWIN_COMPOSE=Q hat gegriffen — die Meldung 'Configured compositor not supported
by Platform' ist verschwunden, KWin compositet jetzt sauber in Software. Die
Grafik ist als Ursache damit ausgeschieden.

Bleibt, dass plasmashell die Shell verwirft. Statt weiter einen Namen zu raten,
werden die tatsächlich vorhandenen Shells nacheinander gestartet, bis eine ohne
'invalid corona' durchläuft. Das ist das brauchbare Abbruchkriterium: es sagt,
dass nichts gezeichnet wird, ohne dass man hinschauen muss.

Dabei die lange Optionsform --shell-plugin statt -p. Kurze Formen ändern sich
zwischen Plasma-Fassungen leichter, und eine unbekannte Kurzoption wird still
ignoriert statt bemängelt — genau der Verdacht.

Trägt keine Shell, wird das Ergebnis als Teilerfolg benannt statt als Fehlschlag:
der Compositor ist der schwierige Teil und bewiesen, die Shell der austauschbare.
Der doppelte Auswertungsblock nach der Schleife ist raus.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 23:02:20 +02:00
StefanandClaude Opus 5 a3a6d7216b S1: Software-Pfad auch dann setzen, wenn gar kein GL nachweisbar ist
Ein Fehler in meiner Verzweigung: schlugen beide GL-Prüfungen fehl, wurden
LIBGL_ALWAYS_SOFTWARE, KWIN_COMPOSE und QT_QUICK_BACKEND NICHT gesetzt —
ausgerechnet dann nicht, wenn sie am nötigsten sind. Der Software-Pfad wurde
dadurch nie ausprobiert.

Dazu ein Denkfehler dahinter: glxinfo taugt hier nicht als Richter. Unter
Termux-X11 scheitert es mit 'BadMatch bei X_GetImage', weil es Pixel zurücklesen
will — das sagt etwas über glxinfo, nichts über OpenGL. Die Prüfungen laufen
jetzt nur noch zur Information; im Zweifel wird immer der Software-Pfad gewählt.

Der virgl-Fehlschlag ist unterdessen als Zeitüberschreitung erkennbar
(Rückgabewert 124): der Client hängt, statt einen Fehler zu melden. Deshalb wird
jetzt vorab geprüft, ob der Socket im Container überhaupt sichtbar ist — das
trennt 'Server läuft nicht' von 'Container sieht ihn nicht'.

Vor Versuch A wird die tatsächlich gesetzte Umgebung ausgegeben, damit man nicht
raten muss, womit gestartet wurde. Beide Zweige durchgespielt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 22:57:47 +02:00
StefanandClaude Opus 5 f3ef48fd10 S1: GL-Prüfung mit Rückgabewert, Software-Rendering als Rückfallebene
Die GPU-Prüfung lieferte auf dem Gerät nicht einmal eine Fehlermeldung — die
Ausgabe war leer. Ursache: stürzt glxinfo ab, kommt die Meldung von der Shell und
nicht vom Programm, und geht in einer Kommandoersetzung verloren. Ein Absturz sah
dadurch aus wie 'kein Treiber gefunden'. Jetzt wird der Rückgabewert ausgewertet
und ein Wert über 128 ausdrücklich als Absturz benannt. Gegen Erfolg, Absturz und
stillen Fehlschlag geprüft.

Davor steht jetzt ein xdpyinfo: ist schon der X-Server aus dem Container nicht
erreichbar, sagt jeder GL-Test darunter nichts aus.

Der wichtigere Punkt ist aber ein Denkfehler im Aufbau: S1 fragt, OB Plasma
Mobile in proot läuft — nicht, wie schnell. Die GPU zur Voraussetzung zu machen
verwechselt Machbarkeit mit Leistung. Schlägt virgl fehl, wird deshalb auf
Software-Rendering ausgewichen und weitergemacht: KWin mit QPainter-Compositor,
QtQuick mit Software-Renderer. Beide umgehen die GL-Ebene ganz und sind für eine
Oberfläche ohne Animationen brauchbarer als llvmpipe.

Damit lässt sich S1 auch dann beantworten, wenn die GPU-Anbindung noch klemmt —
und die wird zu dem, was sie ist: ein eigenes, nachgelagertes Problem.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 22:51:02 +02:00
StefanandClaude Opus 5 c2b602dcb4 S1: GPU im Container über virgl statt Zink — die eigentliche Ursache
Der Protokollauszug enthielt die entscheidende Zeile nicht bei der Shell, sondern
zwei Zeilen darunter:

    ! glxinfo lieferte nichts
    ! vulkaninfo lieferte nichts

Im Container gab es überhaupt kein OpenGL. Mein Denkfehler: Turnip liegt in
Termux' Verzeichnis, nicht im Debian-Rootfs. GALLIUM_DRIVER=zink im Container zu
setzen geht deshalb ins Leere — Zink bräuchte dort einen Vulkan-Treiber, und da
ist keiner.

Damit erklärt sich die ganze Kette: kein OpenGL, also kein QtQuick, also kann
plasmashell die MobileShell nicht laden und fällt wortlos auf die Voreinstellung
zurück. Das 'starting invalid corona' war das Symptom, nicht die Krankheit — und
der schwarze Bildschirm sah nach einem Compositor-Problem aus, obwohl KWin lief.

Richtig ist der Weg über virgl: der Server läuft in TERMUX und rendert dort über
Zink auf Turnip, der Container spricht nur virpipe mit ihm. Turnip bleibt also im
Spiel, nur eine Ebene tiefer als gedacht.

Der GPU-Nachweis im Container wertet jetzt aus statt nur zu drucken und sagt
ausdrücklich, dass ohne OpenGL die Shell nicht laden wird — damit dieselbe
Verwechslung nicht noch einmal Stunden kostet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 22:46:31 +02:00
StefanandClaude Opus 5 d4a6b59f81 S1: Rückfall der Shell erkennen, Empfehlungen mitinstallieren
Die Übergabe an plasmashell ist nachweislich korrekt — geprüft, dass
${SHELL_PAKET:+-p "$SHELL_PAKET"} zu drei getrennten Wörtern expandiert. Und
beide Shells liegen auf dem Gerät: org.kde.plasma.mobileshell und
org.kde.plasma.nano. Trotzdem meldet plasmashell die Voreinstellung
org.kde.plasma.desktop als 'invalid corona'.

Das ist kein Rate-, sondern ein Ladefehler: plasmashell bekam -p, konnte die
MobileShell nicht laden und fiel zurück. Verdacht ist --no-install-recommends —
bei KDE stecken die QML-Module traditionell in den Empfehlungen, nicht in den
harten Abhängigkeiten. Die Shell ist dann formal da, aber innen hohl. Für einen
Machbarkeitsbeweis sind ein paar hundert MB zu viel das kleinere Übel gegenüber
einem Fehlschlag aus dem falschen Grund.

Zusätzlich wertet das Skript den Rückfall jetzt selbst aus und unterscheidet die
beiden Fälle: meldet plasmashell die ÜBERGEBENE Shell als ungültig, liegt es an
ihr; meldet es die Voreinstellung, ist es ein Rückfall. Davon hängt ab, wo man
weitersucht — bisher sah beides gleich aus.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 22:44:11 +02:00
StefanandClaude Opus 5 3643cbd5cb S1: fehlende Plasma-Shell nachinstallieren statt nur melden
In Debian liefert ausgerechnet 'plasma-mobile' keine Shell mit — nur QML-Module
und KWin-Skripte. Die Shell steckt in 'plasma-nano' und heißt org.kde.plasma.nano.
Der aus den KDE-Quellen bekannte Name org.kde.plasma.mobileshell existiert in
Debian nicht.

Auf dem Gerät kam weiterhin 'starting invalid corona org.kde.plasma.desktop' —
das ist plasmashells Standardwert, wenn kein -p übergeben wird. Die Suche fand
also nichts: das Verzeichnis /usr/share/plasma/shells ist leer oder fehlt.

Das Skript gibt sich damit nicht mehr zufrieden, sondern installiert plasma-nano
nach und sucht erneut. Bleibt es dabei, wird der Prüfbefehl genannt und klar
gesagt, dass Versuch A ohne Shell zum Scheitern verurteilt ist — dann zeigt erst
die XFCE-Gegenprobe, ob X-Server und GPU tragen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 22:42:20 +02:00
StefanandClaude Opus 5 985f48177d S1: Plasma-Shell nachsehen statt raten, Beurteilungsfrage gestaffelt
Aus dem Gerätelauf, entscheidende Zeile:

    starting invalid corona "org.kde.plasma.desktop"

Der Paketname der Mobile-Shell hat sich mit Plasma 6 geändert: aus
org.kde.plasma.phoneshell wurde org.kde.plasma.mobileshell. Der falsche Name
fällt nicht auf — plasmashell startet klaglos, meldet nur beiläufig 'invalid
corona' und zeichnet dann nichts. Von außen sieht das aus wie ein Fehlschlag von
KWin, ist aber keiner: der genestete Compositor lief.

Statt einen Namen fest einzutragen, wird jetzt nachgesehen, welche Shells unter
/usr/share/plasma/shells/ tatsächlich liegen, und in der Reihenfolge
mobileshell, phoneshell, nano, desktop gewählt. Die gefundene Liste wird
protokolliert — beim nächsten Umbenennen sieht man sofort, woran es liegt.

Dazu XCURSOR_THEME gesetzt: ohne das meldet KWin 'Failed to load cursor theme'
und zeichnet gar keinen Zeiger.

Die Beurteilungsfrage fragte nach der Bildschirmtastatur in einem Eingabefeld —
in dem Zustand, in dem sie gestellt wird, gibt es aber gar keine Felder. Sie ist
jetzt nach dem gestaffelt, was tatsächlich zu sehen ist, mit dem X-Cursor auf
schwarzem Grund als eigener Zwischenstand: X11 verbunden, aber nichts zeichnet
darauf. Genau dieser Fall lag hier vor und hatte vorher keine passende Antwort.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 22:35:55 +02:00
StefanandClaude Opus 5 ad2c98443b Phase 0: Repo-Gerüst, Dokumentation und Machbarkeits-Spike
Vier Beweise, die das Projekt tragen, als eigenständig lauffähige Skripte:

  S1  Plasma Mobile in proot über genestetes kwin_wayland im X11-Backend.
      Fällt selbsttätig auf startplasmamobile und dann auf XFCE zurück, damit
      ein Fehlschlag eindeutig Plasma zuzuordnen ist und nicht der Umgebung.
  S2  Mikrofon über PulseAudio mit OpenSL-Quelle. Misst den Pegel statt nur die
      Dateigröße — der typische Fehlschlag ist eine formal korrekte WAV-Datei
      voller Stille.
  S3  Virtuelle PipeWire-Kamera per GStreamer-pipewiresink, ohne Kernel-Modul.
      Setzt die Firefox-Einstellung vorab, damit der Test nicht an einem
      vergessenen Häkchen scheitert.
  S4  Intent-Handoff mit lauffähiger Mini-Bridge: xdg-open-Handler für geo:,
      tel: und sms:, Token-Authentifizierung, feste Liste erlaubter Schemata.

provision/provision.sh setzt die Hintergrundbeschränkungen per ADB und benennt,
was ADB nicht kann und von Hand erledigt werden muss.

Dokumentiert sind auch die sieben verworfenen Wege — Waydroid, AVF, QEMU, SIP,
APK-Daten-Redirect, Fenster-Durchreichung und der Android-Server — mit Belegen,
damit sie nicht erneut durchdacht werden müssen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 17:25:36 +02:00