libremarkable VS mxc_epdc_fb_damage

> I rather mean the firmware of the e-ink driver board, which is a trade secret. I don't know, maybe it is not even firmware in an MCU, but they have a dedicated driver chip and it just has the look-up-tables. Anyway, the secret sauce that tells you how to drive the display cells.

Huh? What e-ink driver board? There's no such thing inside a Kindle. It is a straight NXP SoC that drives the e-ink panel directly. There is no MCU. The driver is open source. https://github.com/canselcik/libremarkable/blob/master/refer...

"Secret sauce that tells you how to drive the display cells"? You mean like a voltage table that is also present inside every LCD or OLED? The difference would be that the electrophoretic display would need a much bigger table so it would have to be kept on the SoC. That's not software, that's just a big table of voltages that's hardcoded for each unique panel. Is that what you think is "secret sauce"?

Maybe take a look at https://github.com/canselcik/libremarkable

Well, it'd be easy to test out the latency of a libremarkable demo and compare it to the default software.

First, the remarkable is a fantastic device! However it would be even better (in my opinion) if on the menu of the ui below the "Ebooks" tab there was an "Applications" tab where users could add binaries/applications of there own choosing and run them from within the xochitl ui. There is an active community of hackers and enthusiasts who are writing applications for the remarkable that would greatly appreciate a supported means of running custom programs from within the existing ui, without having to utilize a 3rd-party launcher or leave xochitl. relevant links: https://github.com/LinusCDE/retris https://github.com/canselcik/libremarkable

a) The (actually multitouch capable) finger recognition is a separate piece of hardware to the pen recognition: See https://github.com/canselcik/libremarkable/wiki/Hardware-Overview, especially Reading from Wacom I2C Digitizer Reading Parade TrueTouch Gen5 Multitouch Input

Did you ever look at only transmitting the changed regions of the framebuffer? You can really cut down on data rate that way: https://github.com/pl-semiotics/mxc_epdc_fb_damage

Thats how the rM VNC project does it, but I prefer the UX of your app not needing any client side software.

I wrote rM-vnc-server, although not the rmview client that uses it. Damage detection on rm1 is mxc_epdc_fb_damage, and on rm2 is libqsgepaper-snoop, if you're curious as to the lengths gone to in order to make it work (the latter especially proving to be rather the undertaking).