Ghostwriter nutzt reMarkable 2 als Interface für Vision-LLMs

 (github.com/awwaiid)
1 Punkte von GN⁺ 2025-02-10 | 1 Kommentare | Auf WhatsApp teilen
  • Ghostwriter ist ein experimentelles Projekt, das auf dem reMarkable handschriftliche Eingaben des Nutzers überwacht, sie bei Auslösung durch eine Geste oder den Bildschirminhalt an ein Vision-LLM sendet und das Ergebnis wieder als Text oder Zeichnung auf dem Bildschirm ausgibt
  • Für die Ausführung werden API-Keys wie OPENAI_API_KEY, ANTHROPIC_API_KEY und GOOGLE_API_KEY benötigt; man lädt die Binärdateien für reMarkable2 und reMarkable Paper Pro herunter, kopiert sie auf das Gerät und startet sie per SSH
  • Das Standardmodell ist claude-sonnet-4-0; über --model gpt-4o-mini, --engine openai, --engine anthropic, --engine google, --engine-base-url usw. lassen sich Modell und Engine ändern
  • Als Ausgabe werden sowohl SVG-Zeichnungen als auch Texteingabe über eine virtuelle Tastatur unterstützt; Optionen wie --no-svg, --no-keyboard, --thinking, --web-search und --apply-segmentation passen das Verhalten an
  • Das Projekt wurde um Screenshot-Erfassung, Vision-LLM-Aufrufe, Tool-Nutzung, Bildsegmente, Evaluierungsskripte und Unterstützung für das uinput-Modul des reMarkable Paper Pro erweitert; einige Funktionen sind jedoch ausdrücklich experimentell oder WIP

Was Ghostwriter tut

  • Ghostwriter ist ein experimentelles Interface, das auf dem reMarkable läuft
    • Der Nutzer schreibt oder zeichnet auf dem Bildschirm
    • Eine Berührung einer bestimmten Ecke mit dem Finger oder der Bildschirminhalt löst die Verarbeitung aus
    • Der aktuelle Bildschirm wird an ein Vision-LLM gesendet, und die Modellantwort wird wieder auf dem Bildschirm ausgegeben
  • Als Beispiel ist ein Fall enthalten, in dem der Nutzer einen handgeschriebenen Prompt eingibt und GPT-4o ein Bild eines Chihuahuas zeichnet
  • Ziel des Projekts ist es, verschiedene Interaktionsformen in einem Medium zu erkunden, das Handschrift und Bildschirm kombiniert

Installation und Ausführung

  • Vor der Ausführung müssen in der reMarkable-Umgebung API-Keys gesetzt werden
    • OPENAI_API_KEY
    • ANTHROPIC_API_KEY
    • GOOGLE_API_KEY
  • Die Installation erfolgt, indem man auf dem lokalen Computer die gerätespezifische Binärdatei herunterlädt und auf das reMarkable kopiert
    • reMarkable2: ghostwriter-rm2
    • reMarkable Paper Pro: ghostwriter-rmpp
  • Auf dem Gerät verbindet man sich per SSH, vergibt Ausführungsrechte und startet ./ghostwriter
  • Die Standardausführung nutzt claude-sonnet-4-0
    • ./ghostwriter
    • ./ghostwriter --model gpt-4o-mini
  • Ein Beispiel für die Ausführung im Hintergrund ist nohup ./ghostwriter --model gpt-4o-mini &
  • Automatischer Start beim Booten ist noch als TODO vermerkt

Nutzungsablauf und CLI-Optionen

  • Der Nutzer startet zunächst ghostwriter auf dem reMarkable, zeichnet Inhalte auf den Bildschirm und tippt dann mit dem Finger auf die obere rechte Ecke, um den Assistenten auszulösen
  • Während der Verarbeitung zeigt die SSH-Sitzung Touch-Erkennung und Verarbeitungslogs; auf dem Bildschirm werden Punkte als Fortschrittsanzeige gezeichnet, danach erscheint eine getippte oder gezeichnete Antwort
  • Optionen für Modell und Engine
    • --model MODEL: zu verwendendes Modell, Standard ist claude-sonnet-4-0
    • --engine ENGINE: Auswahl aus openai, anthropic, google; kann anhand des Modells automatisch erkannt werden
    • --engine-api-key KEY: API-Key direkt angeben
    • --engine-base-url URL: benutzerdefinierte API-Basis-URL angeben
  • Verhaltensbezogene Optionen
    • --prompt PROMPT: Prompt-Datei angeben, Standard ist general.json
    • --trigger-corner CORNER: Ecke für den Touch-Trigger angeben, Standard ist UR; UL, LR und LL werden ebenfalls unterstützt
  • Tool-bezogene Optionen
    • --no-svg: SVG-Zeichen-Tool deaktivieren
    • --no-keyboard: Textausgabe deaktivieren
    • --thinking: Thinking von Anthropic aktivieren
    • --web-search: Websuche von Anthropic aktivieren
  • Optionen für Tests und Debugging
    • --log-level LEVEL: info, debug, trace setzen
    • --no-loop: nach einer Ausführung beenden
    • --input-png FILE: PNG-Datei statt Screenshot verwenden
    • --output-file FILE: Ausgabe speichern
    • --save-screenshot FILE: Screenshot speichern
    • --save-bitmap FILE: Rendering-Ergebnis speichern
    • --no-submit: nicht an das Modell senden
    • --no-draw: Ausgabe nicht zeichnen
    • --no-trigger: Touch-Trigger deaktivieren
    • --apply-segmentation: Bildsegmente für räumliches Verständnis hinzufügen

Implementierung und Entwicklungs-Workflow

  • Entwickelt wurde hauptsächlich unter Ubuntu; es läuft auch unter OSX
  • Der Entwicklungsablauf besteht aus Installation der Abhängigkeiten, Cross-Compilation für reMarkable-Ziele, Übertragung per scp auf das Gerät und Neustart auf dem Gerät
  • Für die Cross-Compilation werden Docker, Rust, cross-rs und ARM-Targets verwendet
    • Target für reMarkable2: armv7-unknown-linux-gnueabihf
    • Target für reMarkable Paper Pro: aarch64-unknown-linux-gnu
  • Build und Übertragung sind in build.sh gekapselt
    • ./build.sh: Build und Übertragung für reMarkable2
    • ./build.sh rmpp: Build und Übertragung für reMarkable Paper Pro
  • Release-Builds funktionieren so, dass ein Tag wie v2026.09.21-01 auf main gesetzt wird; eine GitHub Action erstellt dann das neueste Release

Funktionsänderungen und Experimentprotokoll

  • Am 2024-10-06 funktionierte der grundlegende Proof of Concept
    • Ein Beispiel, das die Matheaufgabe 3 + 7 = beantwortet, funktionierte
    • Das Beispiel „Draw a picture of a chihuahua. Use simple line-art“ funktionierte
    • Der Ansatz, SVG-Ausgaben zu rastern und anschließend viele Punkte zu zeichnen, funktionierte auf dem reMarkable teils nicht gut
  • Am 2024-10-07 wurden der Touch-Trigger oben rechts und eine Statusanzeige hinzugefügt
    • Bei Berührung wird ein X auf den Bildschirm gezeichnet, während der Verarbeitung werden zusätzliche Linien zum X hinzugefügt
    • Der Nutzer muss es selbst löschen
  • Ab 2024-10-10 begannen Experimente mit Texteingabe über eine virtuelle Tastatur
    • Jede Seite des reMarkable hat ein großes Textfeld, die Formatierung ist grundlegend
    • Über rM-input-devices wurde validiert, eine virtuelle Tastatur zu erstellen und in die Textebene auszugeben
  • Am 2024-11-02 wurden die Tools draw_text und draw_svg bereitgestellt
    • Ein einzelner Gesamtassistent entscheidet, ob er per Tastaturtext oder SVG-Zeichnung antwortet
  • Am 2024-11-07 wurde Unterstützung für Claude/Anthropic hinzugefügt
    • Es lässt sich nahezu dieselbe Tool-Use-Konfiguration wie bei OpenAI verwenden
    • Es wurde notiert, dass Zeichnen eher bevorzugt zu werden schien, Zeichnen und räumliches Verständnis aber nicht gut waren
  • Am 2024-12-02 wurde ein grundlegender Bildsegmentierungsschritt hinzugefügt
    • Segmentkoordinaten werden an das Vision-LLM übergeben, damit sie berücksichtigt werden
    • Zu diesem Zeitpunkt war dies nur mit Claude verbunden
    • Verbesserungen wurden beim Setzen eines X in eine Box und bei der Platzierung der Antwort zu einer Matheaufgabe dokumentiert
    • Es muss explizit mit --apply-segmentation aktiviert werden und parst PNGs erneut, basierend auf --input-png oder --save-screenshot
  • Am 2024-12-15 wurde eine polymorphe Engine-Schicht für die Backends OpenAI und Anthropic getrennt
    • Engine und Modell können nun als Argumente übergeben werden
    • Prompt- und Tool-Definitionen wurden in das Verzeichnis prompts/ ausgelagert und vereinheitlicht
  • Am 2024-12-25 wurde die CLI vereinfacht und erweitert
    • Wenn nur -m gpt-4o-mini übergeben wird, wird die Engine als openai angenommen
    • Ein Nutzungsbeispiel für Groq wurde hinzugefügt
    • Unterstützung für Google Gemini über gemini-2.0-flash-exp und GOOGLE_API_KEY wurde hinzugefügt
  • Am 2025-05-10 wurden thinking und web_search von Anthropic hinzugefügt
    • Thinking-Antworten werden verarbeitet, aber nicht an den Bildschirm gesendet
    • Websuche funktioniert als serverseitige Anthropic-Funktion
    • Sie ist standardmäßig nicht aktiviert und wird mit ./ghostwriter --thinking --web-search gestartet
  • Am 2025-09-21 wurden Korrekturen und Optionen für reMarkable Paper Pro ergänzt
    • Ein Problem wurde behoben, bei dem Screenshots wegen einer Änderung der Bildschirmauflösung in 3.20 nicht korrekt eingelesen wurden
    • Auf Nutzerwunsch wurde --no-svg hinzugefügt
    • Die Angabe der Trigger-Ecke, z. B. --trigger-corner LR, wurde ergänzt

reMarkable Paper Pro und uinput

  • Am 2025-03-03 lief Ghostwriter auch auf dem reMarkable Paper Pro
  • Etwas andere Bildschirm- und Eingabemethoden waren erwartete Unterschiede
  • Unerwartet war, dass das reMarkable Paper Pro das Kernelmodul uinput nicht enthielt
  • Mit reMarkable/linux-imx-rm wurde das uinput-Modul gebaut und gebündelt
  • Ghostwriter versucht, das uinput-Modul zu laden, falls es nicht bereits geladen ist
  • Da jede reMarkable-Version üblicherweise eine neue Linux-Version verwendet und damit inkompatibel sein kann, ist dieser Teil als große Belastung dokumentiert
  • Am 2025-04-26 waren Module für 3.16, 3.17 und 3.18 vorbereitet
  • In einem Eintrag vom 2025-12-06 heißt es, dass das rmpp-Linux nach einem Update bereits veröffentlicht war und das uinput-Modul bereits existierte, aber noch geladen werden musste

Evaluierung und künftige Ideen

  • Das grundlegende Evaluierungssystem ist als erledigt zusammengefasst
    • Erzeugen eines Screenshot-Sets als Eingabe
    • Abbilden verschiedener Use Cases
    • Erzeugen von Ausgabebeispielen in Text-, SVG- und Aktionsform
    • Teilweise mit der Möglichkeit einer Bewertung durch Menschen oder einen separaten Vision-LLM-Judge
  • Am 2024-12-22 begann der Ausbau des Evaluierungssystems, unter anderem mit run_eval.sh
    • Die damaligen Parameter waren hartcodiert: Nutzung von Segmenten ja/nein sowie Auswahl von Claude 3.5 Sonnet oder ChatGPT 4o-mini
    • Ein früher Evaluierungsbericht ist enthalten
    • Im finalen Bericht gab es 48 Läufe, die Kosten wurden mit etwa 1 $ angegeben
  • Als WIP-Punkt gibt es eine Prompt-Bibliothek
    • In prompts/ gibt es einen Ausgangspunkt
    • Die Idee ist, Tools über Prompts konfigurierbar zu machen
    • Ein Beispiel-Prompt für TODO-Verwaltung enthält den Ansatz, todo zu finden und zu extrahieren und externe Befehle wie add-todo.sh auszuführen
  • Zu den künftigen Ideen gehören das Erzeugen einer initialen Konfigurationsdatei, Eingabe von API-Keys, Autostart und automatische Wiederherstellung, Diagrammerstellung auf Basis von PlantUML oder Mermaid, externe Abfragen sowie Versand per E-Mail oder Slack
  • Es gibt auch eine Idee für einen Konversationsmodus
    • Auf einem Bildschirm werden Bildschirmversionen pro Turn verfolgt
    • Vorgeschlagen ist, ursprüngliche Eingabe, Modellantwort und neue Eingabe farblich zu unterscheiden
    • Außerdem ist vorgesehen, „neuer Prompt“ und „fortsetzen“ über unterschiedliche Trigger zu trennen
  • Es gibt auch Experimente mit Vision-LLMs im lokalen Netzwerk
    • Der OpenAI-API-kompatible Modus von Ollama scheiterte, weil llama3.2-vision keine Tools unterstützt
    • Groqs llama-3.2-vision unterstützt Tools, wird aber als nicht so gut wie ChatGPT, Claude oder Gemini beschrieben
  • Weitere Ideen umfassen Streaming-LLM-Services und Abbruch, asynchrone Verarbeitung, OpenAI Responses API, MCP (Model Context Protocol) und ein integriertes Web-Interface

Referenzierte Ressourcen

  • Awesome reMarkable: Ressourcen rund um reMarkable
  • reSnap: Basis für Bildschirmaufnahmen
  • rmkit lamp: Referenz für Bildschirm-Zeichentechniken
  • resvg: SVG-to-PNG-Verarbeitung
  • rM-input-devices: Erzeugung virtueller Eingabegeräte ohne Tastatur
  • reMarkableAI: verwandtes Projekt mit OCR→OpenAI→PDF→Device-Workflow
  • rMAI: reMarkable-LLM-Interface als separate App
  • Crazy Cow: Tool für reMarkable1, das Text in Stiftstriche umwandelt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-10
Hacker-News-Kommentare

  • Ich bin der Ersteller des Projekts. Es ist weiterhin Work in Progress, und die größte Erkenntnis waren die Grenzen der räumlichen Wahrnehmung von Vision-Modellen.
    Ein grobes Evaluationsbeispiel gibt es unter https://github.com/awwaiid/ghostwriter/blob/main/evaluation_...
    Als Nächstes plane ich, mit einem yaml+Shellscript-basierten Agenten-Framework/Tool weiter zu bauen und zu extrahieren, Methoden zur räumlichen Wahrnehmung wie Vorsegmentierung weiter zu erkunden und ein reSvg-Backend zu schreiben, das echte Stiftstriche statt vieler Punkte sendet.

    • Wirklich großartig. Mir kommt dabei nicht nur eine „schlichte, rundenbasierte“ Nutzung in den Sinn, sondern eine stärker kollaborative Art der Interaktion.
      Wenn man zum Beispiel Notizen schreibt, in denen Wörter, einfache Mathematik und Diagramme gemischt sind, und dann einen zentralen Ausdruck unterstreicht, könnte das „Gerät“ diesen Ausdruck am Rand ausführen.
      Wenn das Gerät ein Diagramm zeichnet und ich dazwischengehe, einen Teil lösche und korrigiere, scheint es möglich, dass es das versteht und entsprechend ändert.
      Die Kombination aus Text aus Handschrifterkennung, Strichgesten, einer kleinen Icon-Sprache und einem LLM könnte ein neues Paradigma der Nutzerinteraktion eröffnen, das wir uns, gefangen in unseren bisherigen Gewohnheiten, nicht sofort vorstellen können.
      Es sieht so aus, als könnte daraus bald ein Moment wie die „Mutter aller Demos“ entstehen, aber da ich kein UX-Designer bin, kann ich es mir nicht klar ausmalen – vielleicht schafft es ja der Ersteller.
    • Der Effekt ist wirklich beeindruckend. Ich frage mich, wie das in der Praxis genutzt werden wird.
      Aus Produktsicht müsste man wohl einen Modus zum Anfordern einer Antwort vom LLM leicht ein- und ausschalten können, damit es nicht jedes Mal weiterantwortet, sobald der Stylus kurz pausiert.
      Man möchte vielleicht eine Weile skizzieren und nachdenken und dann das Gespräch wieder aufnehmen, oder das LLM nur auf bestimmten Seiten einschalten und auf anderen deaktivieren.
      Mich würde auch interessieren, welche Art von Jailbreak nötig ist, um SSH-Zugriff auf das Gerät zu bekommen.

  • Ich finde es wirklich schön zu sehen, wie Apps für das reMarkable-Tablet gehackt und gebaut werden.
    Früher habe ich selbst eine kleine reMarkable-App gebaut und hier geteilt: https://digest.ferrucc.io/

    • Jedes Mal, wenn ich so etwas sehe, bekomme ich Lust, App-Entwicklung für Remarkable 2 auszuprobieren. Gibt es empfehlenswerte Ressourcen?
      Die offizielle Entwicklerseite habe ich gefunden: https://developer.remarkable.com/documentation
    • Cool. Ich sehe gerne, wie die Funktionen des reMarkable durch kreative Hacks erweitert werden.
      Ich habe mir die App angesehen und frage mich, was bei der Entwicklung für reMarkable am schwierigsten war.

  • Ich wünschte, die reMarkable-Tablets wären etwas weniger abgeschottet.
    Es ist eines meiner Lieblingsstücke an Hardware, daher hätte ich gern mehr Apps dafür.

    • Abgeschottet? Wenn man sich per SSH verbindet, bekommt man eine Shell. Wenn das iPad das erlaubt, können wir weiterreden.

  • Seit ein paar Monaten wollte ich so etwas implementieren; das ist wirklich gut umgesetzt.

    • Es ist zwar noch Work in Progress, aber ein sehr interessantes Projekt, um daraus zu lernen und sich inspirieren zu lassen.
      Es steckt auch ein bisschen Rust darin, es geht um den Umgang mit Gerätebeschränkungen, verschiedene Normalisierungen von LLM-APIs, das Schulen räumlicher Vision-LLMs und mehr.
    • Ich wollte goMarkableStream einmal in einen MCP-Server verwandeln.
      Den Bildschirm konnte ich abrufen, aber ohne „Hacking“ konnte ich keine Antworten zurückschreiben.

  • Ich will das dieses Wochenende ausprobieren.
    Ich hatte die Idee, beim Schreiben einer To-do-Liste ein PDF per E-Mail zu verschicken und an ein LLM zu übergeben, um Aufgaben automatisch zu erstellen; das hier eröffnet eine Möglichkeit, dieses Ziel in Echtzeit viel besser zu erreichen.

    • Als ich vor ein paar Monaten mit Claude und rMPP einen Proof of Concept gebaut habe, funktionierte das ziemlich gut.
      Es konnte sogar vage Terminangaben wie „Das will ich irgendwann machen, es gibt keine feste Zeit, also wähle etwas, das nicht mit meinem echten Kalender kollidiert“ verarbeiten.
      Es brauchte kaum Prompting, aber der Workflow war nicht besonders gut, weil ich am Ende doch PDFs per E-Mail verschickte.
      Ich sollte mir das wohl noch einmal ansehen, hatte aber keine Motivation, weil ich die erstellten Aufgaben ohnehin ignorierte.
    • Ich kann helfen, wenn nötig. Bislang scheint es nur etwa eine Person zu geben, die das tatsächlich zum Laufen gebracht hat.
      Ich bin auf dem reMarkable-Discord-Server https://discord.gg/u3P9sDW. Er ist auch unter https://github.com/reHackable/awesome-reMarkable verlinkt.
      Da es ein Rust-Binary ist, sollte die Installation einfach sein. Theoretisch zumindest :)

  • Ich frage mich, ob das auch auf Android-basierten Onyx-Boox-E-Book-Readern möglich wäre.

    • Wegen der Einschränkungen des reMarkable habe ich Screenshots gemacht und Eingabeereignisse injiziert, um mit der proprietären Zeichen-App zu interagieren.
      Unter Android sollten App-übergreifende Screenshots mit den passenden Berechtigungen möglich sein, aber bei der Injektion von Zeichenereignissen bin ich mir nicht sicher.
      Ein anderer Weg wäre, eine dedizierte App zu bauen. Ich habe mir gerade einen Apple Pencil gekauft und überlege, dieses Konzept in eine Web-App zu übertragen; bisher funktioniert das überraschend gut.
      Trotzdem wäre die sauberere Lösung wohl, wenn dieser Agent mit bestehenden Apps interagiert.

  • Die Kombination von Handschrifteingabe und LLMs ist ein hervorragender Use Case für einen viel natürlicheren Workflow.
    Ich frage mich, wie gut es mit unordentlicher Handschrift zurechtkommt und ob sich die Erkennung mit der Zeit verbessert, wenn man es auf persönliche Notizen feinabstimmt.

    • Ich habe das vor ein paar Monaten mit dem Remarkable Paper Pro und Claude ausprobiert, und es funktionierte ziemlich gut.
      Obwohl meine Handschrift ziemlich chaotisch ist, konnte es aus einer Beschreibung dessen, was ich tun wollte, und einer groben oder konkreten Zeitangabe eine ical-Datei erzeugen, die ich in den Kalender eintragen konnte.
    • Wenn ich meine eigene Handschrift lesen kann, kann das Modell sie normalerweise auch lesen. Dieser Teil war kein Problem.
      Das eigentliche Problem liegt eher in der räumlichen Wahrnehmung. Zuverlässig ein X in eine Box zu zeichnen ist schon schwierig, und Tic-Tac-Toe oder Punkt-zu-Punkt-Spiele sind noch schwieriger.

  • Schön. Es gibt auch einige Vektor-Diffusionsmodelle; wenn das Modell entscheidet, etwas zu zeichnen, könnte man das per Tool Call an so ein Modell delegieren.
    Dann ließen sich Koordinatenbereich und Prompt angeben.

    • Aus zwei Gründen. Erstens bin ich noch nicht so weit gekommen, und zweitens … eigentlich nur dieser eine Grund.
      Mich würde interessieren, ob es empfehlenswerte Modelle gibt, idealerweise mit gehosteter API.

  • Ich frage mich, ob die 11-Zoll-Größe des reMarkable zum Lesen von PDF-Papern ausreicht.
    Ich nutze ein 13-Zoll-Sony DPT der zweiten Generation, und zum Lesen ist es perfekt. Trotzdem ziehen mich solche Projekte immer wieder zu reMarkable-Produkten.

    • Ich habe versucht, Paper auf dem Remarkable 2 zu lesen, aber es war ein bisschen zu klein, um den Text bequem zu lesen.
      Da ich eher aktiv lese, vermisse ich auch farbige Hervorhebungen. Die Annotationsfunktionen sind großartig.
      Derzeit prüfe ich Paper weiter in der Zotero-App auf dem iPad.
    • Ich habe mir kürzlich das reMarkable-Pro-Tablet gekauft, und dadurch konnte ich vom Sony DPT-S1 und dem reMarkable 2 umsteigen.
      Das reMarkable 2 war wegen seiner Hackbarkeit interessant, aber die Bildschirmgröße und Farbfunktionen des Pro machen es zu einem hervorragenden Ersatz.
    • Für PDFs ist es gerade so brauchbar.

  • Ich nutze ein Boox-Tablet, das im Grunde ein vollwertiges Android-Tablet mit E-Ink-Display ist, und es scheint für solche Funktionen ideal zu sein.
    Ich frage mich, ob mobile Hardware in etwa fünf Jahren so etwas lokal ausführen können wird.