2 puntos por GN⁺ 2024-08-05 | 1 comentarios | Compartir por WhatsApp
  • En un Kindle Paperwhite 3 se implementó una demo de monitor e-ink de 3.5 fps capturando, transfiriendo y mostrando la pantalla de macOS
  • En el Kindle se dejó un servidor listener en Go que recibe imágenes por el puerto 8000, y dibuja el JPG recibido en pantalla con la utilidad integrada eips
  • En macOS se combinan screencapture, ImageMagick y netcat para capturar la pantalla, convertirla y enviarla por usbnet
  • Como la estructura envía un JPG completo en cada frame, en pantallas con pocos cambios como un editor de texto hay mucho desperdicio de transferencia y bastante margen de mejora
  • Muestra que, incluso sin implementar un códec aparte ni VNC, se puede crear rápidamente un experimento de monitor secundario e-ink solo combinando herramientas existentes

Jailbreak y acceso a root shell

  • El primer paso es hacer jailbreak al Kindle y conseguir acceso al root shell de alguna forma
  • Se puede encontrar material relacionado en mobileread.com, y se pueden seguir las instrucciones del hilo de LanguageBreak
  • El autor no siguió exactamente las instrucciones de LanguageBreak, pero aprovechó de forma útil el repositorio de GitHub de LanguageBreak para depurar
  • Más importante que el método de jailbreak en sí es obtener un root shell en el Kindle

Servidor listener en el Kindle y salida con eips

  • Del lado del Kindle se escribió un programa en Go que recibe archivos por el puerto 8000
  • El listener guarda el JPG recibido y luego invoca eips, la utilidad integrada de salida de pantalla del Kindle
  • Flujo de ejemplo:
    • El programa en Go recibe un archivo JPG
    • Lo guarda en /tmp/img.jpg
    • Muestra la imagen en pantalla con el siguiente comando
eips -g /tmp/img.jpg -w gc16 -x 128 -y 0
  • Este comando muestra la imagen con una actualización parcial
  • La actualización completa no dio buenos resultados, y el significado de las banderas de eips puede consultarse en la wiki de eips
  • Antes del primer frame, se puede limpiar la pantalla con eips -c
  • El código fuente en Go se perdió, pero era un código simple de menos de 30 líneas

Captura de pantalla en macOS y conversión de imagen

  • En macOS se captura repetidamente la pantalla con screencapture y se guarda como archivo PNG
  • La imagen capturada se rota, redimensiona y convierte a escala de grises para ajustarse a la pantalla del Kindle usando ImageMagick
  • El JPG convertido se envía al servidor listener del Kindle por usbnet con netcat
/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 captura la pantalla en /tmp/orig.png
  • convert rota la imagen 270 grados, la redimensiona a 810x1448 y luego la convierte a un JPG de 8 bits en escala de grises y 256 colores
  • nc envía el archivo convertido /tmp/gray.jpg a 192.168.15.244:8000
  • La resolución debe ajustarse según el dispositivo Kindle usado, y el puerto también debe coincidir con la configuración del servidor listener del Kindle

Límites de rendimiento y usabilidad

  • Esta implementación es un hack hecho rápidamente por diversión la noche anterior, y tanto el rendimiento como la usabilidad tienen mucho margen de mejora
  • Enviar el archivo JPG completo en cada frame es muy ineficiente
  • La cantidad de cambios entre frames consecutivos suele ser pequeña y probablemente fácil de comprimir
    • En usos como un editor de texto, donde solo cambia una parte de la pantalla, esta característica puede notarse aún más
  • Incluso sin crear desde cero un códec como h.264 o un protocolo como VNC, parece posible mejorar esto rápidamente solo con herramientas ya existentes

Material de referencia

1 comentarios

 
GN⁺ 2024-08-05
Opiniones de Hacker News
  • Habría sido mucho más interesante si hubiera compartido cómo lo hizo y lo hubiera publicado en un lugar que no fuera una plataforma para textos breves.

    • Ahora estoy armando rápidamente un GitHub gist y voy a publicar el enlace aquí en unos minutos.
      Edición: https://gist.github.com/adtac/eb639d3c707b55a28f0ee9a420aa7e...
    • Yo lo habría dicho de forma más dura, pero creo que lo expresó de manera bastante constructiva. Detesto de verdad que se publiquen textos largos en X/Twitter.
      Para quienes no lo sepan: si responden a un tuit con @threadreaderapp unroll, pueden recibir el documento reconstruido. El bot solo responde directamente a uno mismo después de terminar de desplegar el hilo.
    • Es interesante que veas HN como una plataforma para textos breves.
  • Hice algo parecido con entrada HDMI.
    https://hackaday.com/2021/01/08/old-kindle-shows-hdmi-video-...
    Por eso creé OK Monitor: https://barwap.com/projects/okmonitor/

    • Como referencia, si existiera una versión comercial lista para usar, pagaría por comprarla.
      No creo que tenga viabilidad comercial. Supongo que las ventas estarían en el rango de miles a decenas de miles de dólares, así que, sin importar cómo se calcule el margen, sería difícil recuperar más que el tiempo o el costo invertidos. Aun así, en proyectos hobby a veces he visto que se avanza así para generar impacto.
      Me gustaría tener una pantalla inalámbrica de tinta electrónica para computadora; idealmente, con un dongle USB-C que reciba video y energía al mismo tiempo. HDMI + alimentación por USB también estaría bien.
  • En los últimos días probé Android + Kaleido3 como dispositivo de uso general, y también usé Termux-X11.
    Kaleido3 es bastante usable. Gracias a las formas de onda más recientes y al algoritmo de dithering correcto, incluso se puede ver video con compromisos limitados, y la tasa de cuadros es alta. También pude programar sin problema, y Termux proporcionó compiladores e intérpretes.
    Con Termux-X11 se puede ejecutar Linux de escritorio de forma nativa en un dispositivo Android. Así que no hace falta usar la tinta electrónica como parte de un monitor: también se puede aprovechar directamente como una pantalla de computadora activa integrada en la tablet.

  • Si alguien quiere hacer jailbreak a un Kindle, conviene empezar por los foros de mobileread.

  • ¿Algún día podrán abaratarse las pantallas de tinta electrónica? Me parece que las patentes básicas ya deberían estar por vencer.

    • Los productos competidores también siguen siendo bastante caros. La pantalla de papel electrónico que uso en mi calendario digital, hasta donde sé, no es de E Ink, pero comprada por unidad cuesta unos 50 euros: https://www.waveshare.com/7.5inch-e-paper-hat.htm
      Es el mayor factor de costo en mi calendario y, en la práctica, obliga a fijar el rango de precio: https://shop.invisible-computers.com/products/invisible-cale...
    • https://news.ycombinator.com/item?id=26143779
    • Las patentes no tienen mucho que ver. E Ink es cara porque es un producto de nicho de pequeña escala. Se producen miles de millones de pantallas LCD por trimestre, y es muy probable que cada persona tenga varios dispositivos con LCD.
      La mayoría de lo que hace E Ink se puede reemplazar por LCD, y como es más cara que LCD, hay pocos casos en los que alguien quiera usarla.
      Lo de las “patentes” se parece más a una teoría conspirativa sin una base clara. E Ink tiene competidores, por ejemplo las pantallas DES/Display Electronic Slurry. Si E Ink Corp estuviera cobrando de más, GoodDisplay ya le habría quitado el mercado.
      Para ser precisos, no es una teoría conspirativa decir que existen patentes de E Ink. Algunas ya vencieron, y E Ink Corp sigue innovando y registrando patentes nuevas. También hay muchísimas patentes de LCD. La parte conspirativa es afirmar que las patentes causan aumentos y precios altos, y que por eso impiden la adopción de la tecnología.
  • ¿Por qué hacer jailbreak? ¿No bastaría con transmitir capturas de pantalla del escritorio usando el navegador integrado del Kindle?

    • Eso sí sería mucho más simple. Pero todos los frames tendrían que pasar por red → DOM → memoria de la app del navegador → framebuffer, así que soy escéptico de que el navegador sea lo bastante potente como para manejar una tasa de cuadros usable.
      El navegador de Kindle apenas puede con la Kindle Store o Goodreads, pero me encantaría que se demostrara lo contrario. Así sería mucho más fácil implementarlo en un Kindle nuevo sin modificarlo.
  • Lo que aparece en GitHub: “Lamentablemente perdí el código fuente en Go”.

    • Y luego dijo: “Aun así, era bastante simple y tenía menos de 30 líneas”.
      Si era tan simple, resulta más bien raro que no pudiera reescribirlo de inmediato y agregarlo a GitHub.
  • Para hacer esto fácilmente, basta con usar la app Superdisplay en un lector Boox.

  • No respondió la pregunta más importante: ¿valió la pena intentarlo?

    • Todavía es temprano para juzgar. No es útil como monitor principal, pero como monitor secundario es excelente.
      En su forma actual, la tasa de cuadros es buena, pero la latencia es terrible. Por eso la experiencia al escribir es mala, aunque hay muchos usos que no requieren tipear.
      Incluso en casos donde es importante tener baja latencia al escribir, como una ventana de chat, se puede dejar el cuadro de entrada de texto en un monitor LCD y mostrar en el Kindle solo el historial de chat, que es mayormente estático. Para llegar a eso hace falta más trabajo, pero por ahora es un buen punto de partida.