reMarkable Streaming Tool v2 : améliorer l’efficacité du télétravail

 (blog.owulveryck.info)
3 points par GN⁺ 2023-08-21 | 1 commentaires | Partager sur WhatsApp
  • L’outil qui servait à partager des croquis reMarkable 2 pendant les visioconférences a été modifié pour s’ouvrir sans service local sur l’ordinateur portable, ce qui permet au présentateur de lancer un streaming instantané avec un simple navigateur
  • La nouvelle architecture est simplifiée autour d’un serveur HTTP interne au reMarkable et d’un client JavaScript dans le navigateur, qui reçoit les images brutes et les dessine dans un canvas
  • L’alternative WebSocket fonctionnait, mais des problèmes sur iOS et la surcharge côté serveur subsistaient ; l’approche finale utilise donc un flux brut, en écrivant en continu des images de résolution fixe via http.ResponseWriter et en les lisant avec un flux fetch
  • Une trame brute 1872x1404 pèse environ 2,5 Mo ; depuis le firmware 3.3, les 16 valeurs de couleur sont empaquetées en uint4, ce qui réduit la taille de 50 %, puis RLE abaisse le volume moyen transmis à environ 200 Ko
  • La surveillance de /dev/input/event* arrête l’envoi de nouvelles trames lorsqu’il n’y a pas d’entrée ; même avec des clients connectés, l’utilisation CPU retombe à 0, et pendant l’écriture elle est d’environ 10 % de CPU

Pourquoi l’ancien outil était peu pratique

  • L’outil de streaming reMarkable créé en 2021 servait à partager des croquis pendant les visioconférences ; il suffisait de partager un onglet de navigateur, ce qui facilitait la concentration sur la présentation
  • L’ancienne implémentation était divisée en trois composants
    • Serveur : exécuté sur l’appareil reMarkable, il expose l’image brute de l’écran actuel
    • Client : sur l’ordinateur portable, il récupère l’image brute du serveur et la traite dans un format lisible par le navigateur
    • Moteur de rendu : lit un flux HTTP MJPEG, comme un navigateur ou VLC, et l’affiche à l’écran
  • Pour réduire l’utilisation CPU de l’appareil, le serveur n’extrayait les images que lorsqu’un client était connecté, et la communication utilisait gRPC
  • Le client sur l’ordinateur portable récupérait les images en boucle, les encodait en JPEG, puis exposait un flux MJPEG via un service HTTP
  • Dans un contexte de présentation, la configuration réseau — adresse du reMarkable, droits d’exécution du client, IP du client que le moteur de rendu devait connaître — devenait contraignante

Une nouvelle architecture accessible uniquement depuis le navigateur

  • Le nouvel objectif était de permettre l’accès au flux depuis n’importe quel navigateur en saisissant simplement l’adresse du reMarkable
  • Le client séparé sur ordinateur portable a été supprimé, et un serveur HTTP a été intégré dans le composant serveur du reMarkable
  • Le client à exécuter dans le navigateur devait prendre la forme de JavaScript ou de WASM
    • Au départ, une compilation WASM a été envisagée afin de tirer parti de l’expérience en Go, mais elle a été abandonnée en raison de limitations nécessitant des modifications importantes
    • La deuxième version du client a finalement été écrite en JavaScript
  • ChatGPT a été utilisé pour obtenir des extraits de code JavaScript et des explications, mais l’orientation de la solution recherchée a été définie directement

Rendu avec canvas

  • Pour s’affranchir du flux MJPEG, l’implémentation utilise canvas, l’élément de base du navigateur pour la manipulation d’images
  • L’image brute reçue du reMarkable est lue dans un Uint8Array, puis la même valeur est placée dans les canaux R/G/B des données de pixels RGBA d’un ImageData, avec une valeur alpha fixée à 255 pour l’affichage
  • Afin de permettre un affichage responsive, la rotation et une éventuelle colorisation, un fixedCanvas de taille fixe est conservé masqué
  • Le canevas d’affichage copie le contenu du canevas masqué avec drawImage
  • Lorsque la taille de la fenêtre du navigateur change, la largeur et la hauteur du canevas d’affichage sont ajustées à partir de la taille du conteneur et du ratio 1872/1404

Abandon de WebSocket au profit d’un flux brut

  • gRPC n’étant pas un choix courant en développement web, la première implémentation de remplacement utilisait WebSocket comme moyen de communication et d’encapsulation
  • Les messages WebSocket contenaient les images brutes, et le client navigateur mettait à jour le canevas à chaque message reçu pour donner l’impression d’un streaming
  • Cette approche permettait de gérer la charge mémoire et CPU du reMarkable en ajustant la fréquence d’envoi des messages côté serveur
  • Mais des problèmes apparaissaient sur iOS, et la surcharge de l’implémentation WebSocket côté serveur restait difficile à contrôler
  • L’architecture finale supprime l’encapsulation et transmet directement l’image brute sur le réseau en s’appuyant sur une taille d’image fixe
    • Le serveur Go Write les images en boucle dans http.ResponseWriter
    • Le client navigateur lit le ReadableStream de fetch('/stream') et répercute les chunks reçus dans les données du canevas

Optimisation du volume transmis

  • L’image brute du reMarkable 2 pèse environ 2,5 Mo en résolution 1872x1404, et ces données doivent être transmises à chaque trame
  • Depuis le firmware 3.3, les 16 valeurs de couleur du reMarkable peuvent être représentées sous forme de tableau uint4 au lieu de uint8
    • Go et JavaScript ne disposent pas de type uint4 natif
    • Le contournement consiste à stocker deux valeurs de pixel dans un seul octet uint8
    • En Go, deux valeurs uint4 sont empaquetées dans les 4 bits de poids fort et les 4 bits de poids faible ; en JavaScript, elles sont ensuite dépaquetées
    • Cette représentation permet de réduire le volume de données de 50 %
  • La compression supplémentaire utilise le Run Length Encoding (RLE)
    • RLE est un algorithme simple qui transmet ensemble le nombre de répétitions consécutives d’une même valeur de pixel et cette valeur
    • L’exemple 0 0 0 0 0 0 1 1 1 0 0 0 0 devient 6 0 3 1 4 0
  • La valeur de comptage pouvant atteindre 1872*1404, un type comme uint64 pourrait être nécessaire, et dans certains cas le résultat compressé pourrait devenir plus gros que l’original
  • Pour éviter cela, la longueur du compteur est limitée à 15, et un compromis a été choisi en plaçant le compteur et la valeur de pixel dans un seul octet
  • L’implémentation RLE se comporte comme un io.Writer en Go, ce qui la rend réutilisable ; RLE pourrait aussi être appliqué deux fois si nécessaire, mais cela n’a pas été utile jusqu’à présent
  • Après empaquetage et RLE, le volume moyen transmis est d’environ 200 Ko

N’envoyer des trames qu’en cas de changement

  • La dernière optimisation consiste à n’envoyer une nouvelle trame que lorsque l’écran change
  • Calculer le changement via une somme de contrôle pourrait alourdir la charge CPU
  • Comme le reMarkable repose sur Linux, les entrées stylet ou tactiles sont transmises via /dev/input/event*
  • Une goroutine surveille ces événements d’entrée et n’envoie l’image qu’en cas de besoin
  • En l’absence d’événement, l’utilisation CPU retombe à 0 même lorsqu’un client est connecté
  • Pendant l’écriture, l’utilisation CPU est d’environ 10 %

Changements de firmware et charge de maintenance

  • Cette application repose sur du hacking, et le principal défi consiste à bien séparer l’interface de récupération des images du client et du moteur de rendu
  • L’implémentation précédente découplait complètement client et serveur au moyen de définitions protobuf
  • Le firmware reMarkable 3.3 a cassé l’outil ; les détails figurent dans l’issue 36 sur GitHub
    • À l’époque, le correctif ne touchait que le composant client
  • Le firmware 3.6 pourrait également introduire des changements cassants d’après l’issue 58 sur GitHub
    • Dans ce cas, des modifications plus larges pourraient être nécessaires
    • Toutefois, comme le client est intégré au serveur dans une structure autonome, la mise à jour sur l’appareil pourrait devenir plus simple
  • L’application et le code source sont disponibles sur github.com/owulveryck/goMarkableStream

À lire aussi

1 commentaires

 
GN⁺ 2023-08-21
Avis de Hacker News

  • L’outil de 2021 qui permettait de streamer l’écran d’une tablette reMarkable vers un ordinateur portable a été repris, peaufiné et publié à nouveau ; le nouvel article détaille en profondeur l’architecture, les composants et le processus d’amélioration de l’expérience utilisateur.
    Du point de vue d’un product manager, l’auteur a observé le ressenti des utilisateurs, simplifié le processus d’activation, fait en sorte que l’outil fonctionne sans service local et optimisé l’usage du réseau.

    • Ça ressemble à un chouette projet. Après Ctrl-C puis un redémarrage avec ./goMarkableStream, ça fonctionne dans une certaine mesure, mais waiting for reMarkable screen s’affiche encore souvent et le service reste instable.
      Je l’ai installé après avoir mis mon reMarkable2 à jour en 3.5.2.1807, mais rien ne réagit quand je dessine sur un carnet, une feuille ou un livre, et je vois parfois des logs comme read /dev/input/event2: file already closed ou read /dev/input/event1: file already closed.
      https://192.168.8.143:2001/ et https://10.11.99.1:2001/ servent tous les deux le HTML et le canvas, et j’ai aussi essayé avec Chrome, Firefox et Brave.
      On dirait qu’il y a une limite d’un navigateur et d’une IP par stream, mais quelle que soit l’adresse ou le navigateur utilisés, waiting for reMarkable screen apparaît parfois. Après nohup ./goMarkableStream &, puis fermeture de PuTTY et redémarrage du client, tous les navigateurs se sont retrouvés dans le même état, et https://10.11.99.1:2001/stream renvoie too many requests. Je me demande comment redémarrer le stream.
    • Je me demande si on pourrait aussi l’implémenter via une connexion USB.

  • Comme alternative, j’utilise SuperNote avec beaucoup de satisfaction. Le mirroring d’écran est possible, ce qui est très pratique pour dessiner rapidement des diagrammes pendant des réunions.
    L’inconvénient, c’est que SuperNote lance un petit serveur web auquel on se connecte avec Firefox ; il faut donc que l’ordinateur portable et la SuperNote soient sur le même réseau. En télétravail, ce n’est pas un problème, mais la politique de l’entreprise peut le bloquer.
    Que ce soit la RM2 ou la SuperNote, ce sont d’excellents outils pour les personnes qui aiment poser leurs idées au stylo et au papier ; la sensation est assez différente de celle d’une app ou d’un document texte, et on peut aussi gribouiller dans ses notes.
    [0] : https://supernote.com/.

    • Onyx Boox Note fonctionne bien aussi, et reçoit encore des mises à jour plus de cinq ans après sa sortie.
      En revanche, à l’achat, il faut accepter une violation de la GPL. Même si l’appareil est entièrement basé sur Android, ils ne publient pas les sources du système d’exploitation.
    • Je cherchais une tablette à encre électronique faisant à la fois liseuse et prise de notes, donc la recommandation m’aide. J’hésitais entre la Remarkable 2 et la Boox, et je me demande à quoi ressemble l’expérience des mises à jour logicielles de SuperNote.
      J’ai peur d’acheter un appareil qui ne recevra pas de mises à jour fonctionnelles, ni même au minimum de mises à jour de sécurité, pendant les 3 à 5 prochaines années.
    • Dans mon souvenir, SuperNote ne respectait pas la GPL pour les logiciels distribués avec l’appareil ; je me demande s’ils ont changé de position.
    • Je n’ai pas encore rencontré le problème de « devoir être sur le même réseau », mais ajouter une fonctionnalité Ngrok native semble être une tâche simple qui prendrait quelques minutes. Cela permettrait de streamer via Internet.
    • Je me demande comment la sensation d’écriture de la SuperNote se compare à celle de la RM2.

  • Le rendu sur canvas HTML pourrait être plus rapide en utilisant des tableaux typés, comme expliqué ici : https://hacks.mozilla.org/2011/12/faster-canvas-pixel-manipu....

    • Merci, je vais regarder ça.

  • C’est exactement le genre de contenu que j’aimerais voir ici. J’ai aimé la façon dont ChatGPT a aidé à apprendre et à résoudre des problèmes dans un domaine qu’il connaît mal, et la formule « j’étais le développeur et ChatGPT était le codeur » m’a parlé.
    L’idée que la simplicité est en réalité complexe est juste aussi.

  • Le choix de JPEG vient probablement du fait qu’il est facile de passer à MJPEG et que, si on le transmet à un composant qui le prend en charge, le décodage est pratiquement gratuit. Cela dit, c’est peut-être aussi ce qui met une forte charge sur le CPU du reMarkable.
    JPEG est plus adapté aux photos, alors que l’écran du reMarkable ressemble davantage à de l’illustration et, en plus, il est en niveaux de noir et blanc. D’autres formats d’image courants comme PNG, ou même une simple compression RLE, réduiraient sans doute la charge CPU.

    • À strictement parler, le reMarkable n’est pas monochrome mais en niveaux de gris et, de mémoire, prend en charge 16 niveaux de gris. Dans l’application compagnon, il existe aussi des encres de couleur, comme le bleu et le rouge pour le stylo, ou le jaune et le vert pour le surligneur.
      Et le format de fichier propriétaire est basé sur les entrées manuscrites, pas sur un bitmap.
    • C’est bien pour cette raison que j’ai choisi JPEG au départ. Mais c’est aussi pour cela que j’ai opté pour une architecture client/serveur : l’encodage était effectué sur le client, c’est-à-dire l’ordinateur portable, et non sur la tablette.
      Le profiling a montré que la majeure partie du CPU était utilisée pour le transfert des données par le câble, d’où l’ajout de la compression. Aujourd’hui, l’utilisation CPU est faible.

  • Je me demande si vous avez envisagé de n’envoyer que les zones modifiées du framebuffer. Cela pourrait réduire fortement le débit de données : https://github.com/pl-semiotics/mxc_epdc_fb_damage
    Le projet rM VNC fait aussi comme ça, mais je préfère l’expérience utilisateur de cette app, qui ne nécessite aucun logiciel côté client.

    • Le problème de cette approche, c’est qu’elle exige un certain niveau d’analyse sur l’appareil, alors que je veux garder le code aussi peu intrusif que possible. Je vais voir s’il existe un moyen peu coûteux de le faire.

  • C’est vraiment sympa et j’aimerais aimer la ReMarkable 2, mais ce n’est pas simple à cause de sa réputation d’appareil non sécurisé : https://support.remarkable.com/s/article/Does-reMarkable-off...

    • Le contenu du lien signifie que cet appareil n’offre qu’un niveau de sécurité physique équivalent à celui du papier qu’il cherche à remplacer. Autrement dit, si quelqu’un accède à l’appareil, il peut le lire
      Il ne s’agit pas de vulnérabilités logicielles connues, comme celles auxquelles on pense souvent quand on parle d’un appareil non sécurisé connecté au réseau
    • Il est possible, de manière non officielle, d’activer un chiffrement du répertoire personnel basé sur gocryptfs : https://github.com/RedTeamPentesting/remarkable-encryption
    • Le logiciel est également très limité pour l’instant. Dommage qu’il ne permette pas officiellement d’utiliser une marketplace ou des extensions sur l’appareil
    • Existe-t-il des liseuses qui proposent un chiffrement complet du disque ?

  • J’aimerais en savoir plus sur la partie : « Au début, j’ai essayé de compiler le client en WASM. Cela semblait prometteur, car je pouvais tirer parti de mon expérience de développement en Go, mais je me suis heurté à plusieurs limites qui nécessitaient d’importantes modifications »

    • Le principal problème venait de la bibliothèque gRPC, dont la prise en charge est actuellement très limitée. De plus, en Go, la compression JPEG est lente et très consommatrice de CPU
      Même en générant un flux MJPEG, il restait à savoir comment l’afficher. J’ai pensé à une approche avec canvas, mais il était difficile d’accéder au backend du canvas sans effectuer de grosses copies entre WASM et JS, et la taille atteignait 2,5 Mo
      Au final, en dépendant de WASM, il semblait qu’il faudrait réimplémenter soi-même beaucoup d’opérations d’image de base accessibles nativement en JS, comme la rotation d’image

  • Je me demande en quoi cet outil diffère du streaming intégré, c’est-à-dire de la fonction de partage d’écran

    • Pour utiliser la fonction intégrée, il faut installer l’application de bureau et, à ma connaissance, il n’existe pas de version Linux
      https://support.remarkable.com/s/article/Screen-Share
      La solution décrite dans l’article semble fonctionner aussi sous Linux, tant qu’on dispose d’un navigateur suffisamment capable
    • La plus grande différence est qu’il n’est désormais plus nécessaire d’installer un client. Il suffit de saisir l’adresse de la reMarkable dans le navigateur pour voir le contenu
    • Je pensais que cette fonctionnalité existait déjà. Le partage d’écran est tout à fait correct, et je l’utilise aussi pour du streaming en direct

  • J’aime bien reMarkable, mais j’aimerais qu’ils se concentrent sur ce genre de fonction de streaming plutôt que sur un abonnement que je n’ai pas l’intention de payer à l’avenir