2 Punkte von GN⁺ 2024-08-05 | 1 Kommentare | Auf WhatsApp teilen
  • Auf einem Kindle Paperwhite 3 wurde eine Demo eines 3,5-fps-E-Ink-Monitors umgesetzt, indem der macOS-Bildschirm erfasst, übertragen und angezeigt wird
  • Auf dem Kindle läuft auf Port 8000 ein Go-Listener-Server, der Bilder empfängt und die eingegangenen JPGs mit dem integrierten Utility eips auf den Bildschirm zeichnet
  • Unter macOS übernehmen screencapture, ImageMagick und netcat gemeinsam die Bildschirmaufnahme, Umwandlung und Übertragung per usbnet
  • Da bei jedem Frame das komplette JPG gesendet wird, ist die Übertragungsverschwendung bei Bildschirmen mit wenig Änderungen wie Texteditoren groß und bietet viel Raum für Verbesserungen
  • Es zeigt, dass sich auch ohne eigenen Codec oder eine VNC-Implementierung mit vorhandenen Tools schnell ein Experiment für einen E-Ink-Zweitmonitor bauen lässt

Jailbreak und Root-Shell-Zugriff

  • Der erste Schritt ist, den Kindle zu jailbreaken und auf irgendeine Weise Zugriff auf eine Root-Shell zu bekommen
  • Relevante Informationen finden sich auf mobileread.com, außerdem kann man sich an den Anweisungen im LanguageBreak thread orientieren
  • Der Autor hat die LanguageBreak-Anleitung nicht exakt befolgt, das LanguageBreak-GitHub-Repository aber nützlich zum Debuggen verwendet
  • Wichtiger als die konkrete Jailbreak-Methode ist, dass man auf dem Kindle eine Root-Shell erhält

Kindle-Listener-Server und Ausgabe mit eips

  • Auf der Kindle-Seite wurde ein Go-Programm geschrieben, das auf Port 8000 Dateien empfängt
  • Der Listener speichert das empfangene JPG und ruft anschließend das integrierte Kindle-Utility eips zur Bildausgabe auf
  • Beispielablauf:
    • Das Go-Programm empfängt eine JPG-Datei
    • Es speichert sie unter /tmp/img.jpg
    • Dann wird sie mit folgendem Befehl auf dem Bildschirm angezeigt
eips -g /tmp/img.jpg -w gc16 -x 128 -y 0
  • Dieser Befehl zeigt das Bild per partial update an
  • Ein full update lieferte keine guten Ergebnisse; die Bedeutung der eips-Flags ist im eips wiki nachzulesen
  • Vor dem ersten Frame kann der Bildschirm mit eips -c geleert werden
  • Der Go-Quellcode ist verloren gegangen, war aber ein einfacher Code mit weniger als 30 Zeilen

macOS-Bildschirmaufnahme und Bildkonvertierung

  • Unter macOS wird der Bildschirm wiederholt mit screencapture aufgenommen und als PNG-Datei gespeichert
  • Das aufgenommene Bild wird mit ImageMagick passend zum Kindle-Bildschirm gedreht, skaliert und in Graustufen umgewandelt
  • Das konvertierte JPG wird anschließend mit netcat über usbnet an den Listener-Server auf dem Kindle übertragen
/usr/sbin/screencapture -C -x /tmp/orig.png
convert /tmp/orig.png -rotate 270 -resize '810x1448!' -type GrayScale -depth 8 -colors 256 /tmp/gray.jpg
cat /tmp/gray.jpg | nc -w 0 192.168.15.244 8000
  • screencapture -C -x erfasst den Bildschirm und speichert ihn als /tmp/orig.png
  • convert dreht das Bild um 270 Grad, skaliert es auf 810x1448 und wandelt es dann in ein 8-Bit-Graustufen-JPG mit 256 Farben um
  • nc sendet das umgewandelte /tmp/gray.jpg an 192.168.15.244:8000
  • Die Auflösung muss an das verwendete Kindle-Gerät angepasst werden, und der Port muss zur Konfiguration des Listener-Servers auf dem Kindle passen

Grenzen bei Leistung und Bedienbarkeit

  • Diese Umsetzung ist ein schneller Hack, der am Vorabend aus Spaß gebaut wurde, und bietet sowohl bei Leistung als auch Bedienbarkeit viel Verbesserungspotenzial
  • Das Senden der kompletten JPG-Datei bei jedem Frame ist verschwenderisch
  • Die Unterschiede zwischen aufeinanderfolgenden Frames sind meistens klein und vermutlich leicht zu komprimieren
    • Besonders bei Anwendungen wie Texteditoren, bei denen sich nur Teile des Bildschirms ändern, dürfte das noch deutlicher werden
  • Auch ohne einen Codec wie h.264 oder ein Protokoll wie VNC neu zu entwickeln, sollte sich mit bereits vorhandenen Tools schnell etwas Besseres bauen lassen

Referenzen

1 Kommentare

 
GN⁺ 2024-08-05
Meinungen auf Hacker News
  • Es wäre viel interessanter gewesen, wenn sie erklärt hätten, wie sie es gemacht haben, und es nicht auf einer Plattform für Kurzbeiträge veröffentlicht hätten.

    • Ich schreibe gerade schnell einen GitHub Gist und poste den Link hier in ein paar Minuten.
      Nachtrag: https://gist.github.com/adtac/eb639d3c707b55a28f0ee9a420aa7e...
    • Ich hätte es wohl schärfer formuliert, aber das ist ziemlich konstruktiv ausgedrückt. Ich hasse es wirklich, lange Texte auf X/Twitter zu posten.
      Für alle, die es nicht kennen: Wenn man auf einen Tweet mit @threadreaderapp unroll antwortet, bekommt man ein rekonstruiertes Dokument. Der Bot antwortet nach dem Entrollen nur direkt an einen selbst.
    • Interessant, dass du HN als Plattform für Kurzbeiträge siehst.
  • Ich habe bei einem ähnlichen Projekt einen HDMI-Eingang ausprobiert.
    https://hackaday.com/2021/01/08/old-kindle-shows-hdmi-video-...
    Daraus ist OK Monitor entstanden: https://barwap.com/projects/okmonitor/

    • Nebenbei: Wenn es eine fertige Version von der Stange gäbe, die einfach direkt funktioniert, würde ich dafür bezahlen.
      Ich glaube nicht, dass das wirtschaftlich tragfähig wäre. Der Umsatz läge vermutlich im Bereich von ein paar Tausend bis Zehntausenden Dollar, sodass man bei keiner sinnvollen Marge die investierte Zeit oder die Kosten wieder hereinholen würde. Trotzdem habe ich bei Hobbyprojekten gelegentlich gesehen, dass sie wegen ihrer Wirkung so weitergeführt werden.
      Ich fände ein drahtloses E-Ink-Display für Computer gut, idealerweise in Form eines USB-C-Dongles, der Bildsignal und Strom zusammen liefert. HDMI plus USB-Strom wäre auch in Ordnung.
  • In den letzten Tagen habe ich Android + Kaleido3 als Allzweckgerät getestet und auch Termux-X11 ausprobiert.
    Kaleido3 ist ziemlich brauchbar. Dank aktueller Wellenformen und der richtigen Dithering-Algorithmen kann man mit nur begrenzten Kompromissen sogar Videos ansehen, und die Framerate ist hoch. Programmieren ging ebenfalls gut; Compiler und Interpreter kamen über Termux.
    Mit Termux-X11 kann man Desktop-Linux nativ auf einem Android-Gerät ausführen. Damit muss man E-Ink nicht als Teil eines Monitor-Geräts verwenden, sondern kann es direkt als in ein Tablet integrierten, aktiven Computerbildschirm nutzen.

  • Wer ein Kindle jailbreaken will, sollte im mobileread-Forum anfangen.

  • Könnten E-Ink-Displays irgendwann einmal billig werden? Die grundlegenden Patente müssten doch inzwischen allmählich auslaufen.

    • Auch Konkurrenzprodukte sind weiterhin ziemlich teuer. Das E-Paper-Display, das ich in meinem digitalen Kalender nutze, ist meines Wissens kein Produkt von E Ink, kostet einzeln aber etwa 50 Euro: https://www.waveshare.com/7.5inch-e-paper-hat.htm
      Es ist der größte Kostenfaktor in meinem Kalender und bestimmt praktisch zwangsweise die Preisklasse: https://shop.invisible-computers.com/products/invisible-cale...
    • https://news.ycombinator.com/item?id=26143779
    • Patente spielen kaum eine Rolle. E Ink ist teuer, weil es ein Nischenprodukt mit kleinem Volumen ist. LCD-Bildschirme werden jedes Quartal zu Milliarden produziert, und die meisten von uns besitzen wahrscheinlich mehrere Geräte mit LCDs.
      Das meiste, was E Ink leistet, lässt sich durch LCDs ersetzen, und da es teurer ist als LCD, gibt es nur wenige Einsatzbereiche, in denen man es unbedingt verwenden will.
      „Patente“ sind eher eine Verschwörungstheorie ohne klare Grundlage. Es gibt auch Konkurrenzprodukte zu E Ink, zum Beispiel DES-/Display-Electronic-Slurry-Bildschirme. Wenn E Ink Corp Wucherpreise verlangen würde, hätte GoodDisplay den Markt längst übernommen.
      Genau genommen ist es keine Verschwörungstheorie, dass E-Ink-Patente existieren. Einige sind ausgelaufen, und E Ink Corp meldet durch Innovation weiter neue Patente an. Auch LCD-Patente gibt es in riesiger Zahl. Der verschwörungstheoretische Teil ist die Behauptung, Patente würden Preiserhöhungen und hohe Preise verursachen und dadurch die Verbreitung der Technologie verhindern.
  • Warum überhaupt jailbreaken? Man könnte doch über den eingebauten Kindle-Browser Desktop-Screenshots streamen.

    • Das wäre tatsächlich viel einfacher. Allerdings müsste jedes Frame den Weg Netzwerk → DOM → Speicher der Browser-App → Framebuffer nehmen, und ich bin skeptisch, ob der Browser stark genug ist, um eine brauchbare Framerate zu schaffen.
      Der Kindle-Browser kommt schon mit dem Kindle Store oder Goodreads gerade so mit, aber ich würde mich gern vom Gegenteil überzeugen lassen. Dann ließe sich das auf neuen Kindles im Auslieferungszustand deutlich einfacher umsetzen.
  • Auf GitHub steht: „Leider habe ich den Go-Quellcode verloren.“

    • Danach heißt es: „Er war aber ziemlich simpel und hatte weniger als 30 Zeilen.“
      Wenn er so simpel war, ist es eher merkwürdig, dass er ihn nicht einfach neu geschrieben und zu GitHub hinzugefügt hat.
  • Wenn man das einfach machen will, kann man einen Boox-Reader mit der Superdisplay-App verwenden.

  • Die wichtigste Frage wurde nicht beantwortet: Hat es sich gelohnt, das auszuprobieren?

    • Dafür ist es noch zu früh. Als Hauptmonitor ist es nicht nützlich, als Zweitmonitor aber großartig.
      In der aktuellen Form ist die Framerate gut, aber die Latenz furchtbar. Dadurch ist das Tippgefühl schlecht, aber es gibt viele Anwendungen, die kein Tippen erfordern.
      Selbst in Fällen wie einem Chatfenster, in denen Tipp-Feedback mit niedriger Latenz wichtig ist, kann man das Texteingabefeld auf dem LCD-Monitor lassen und nur den größtenteils statischen Chatverlauf auf dem Kindle anzeigen. Bis dahin ist noch weitere Arbeit nötig, aber fürs Erste ist es ein guter Ausgangspunkt.