"Multiple and proprietary algorithms"? It's just an ordinary control problem, how hard can it be to come up with an openly-available solution? Ultimately, quality/latency/etc. will be a matter of how much effort the user will put in calibrating the driver to their screen.
The waveform flash memory file contains temperature look-up tables (LUTs), waveform sequence data, algorithm data, voltage data, controller settings, and manufacturing data. Each AF waveform is specifically adjusted for a particular display module lot. This specification document is for use by E Ink Corporation and their customers under non-disclosure agreements. E Ink Corporation will be responsible for maintaining and controlling specification revisions.
To my knowledge, there are very few reverse engineered waveform files or custom controllers for eink displays, and those that exist have inferior display properties compared to the e-ink provided waveform tables.
Inputs: temperature, particular display's batch characteristics, what you want to draw, what was drawn on the display in the past, available timing options for how long you can leave gate open for each row, vcom voltage, other voltages (there are 4), how long since last full refresh clear, ...
It's not so much of a problem to have a nice output if you can always do a full screen clear and then paint your image. But that's quite power intensive thing to do and disruptive to the user.
Other than that, with no prior knowledge or know how from eInk, you'll be struggling with previous image reappearing from the dead in parts of the display even after "full screen clear" after a few updates, ghosting, grayscale support, and crap like that.
And you'll have to do all the calculations in real-enough time on a CPU so that you can keep up with raw refresh rate requirements (85Hz). On this high a resolution it will probably be quite a lot of work, and you'll need to code everything up in NEON C intrinsics or assembly.
So while it may be an ordinary control problem, it will be a bit of a struggle. I'm not aware of anyone going this deep. Most of the semi-open implementations are using proprietary waveform data/violating GPL (Pocketbook) with a closed source kernel driver/or hiding the complexity in the HW controller.
It will certainly be interesting to watch how will people deal with this, because it will need a unique intersection of knowledge and dedication.
I follow EPDiy, a project to drive ED097OC4, ED060SC4 and ED097TC2 displays with an ESP32 [0]. While I’m not going to shrug off Valentin’s work as trivial, it doesn’t seem like magic. The hype around the difficulty driving e-ink displays appears over-hyped.
There may be many details to get it perfect, but displaying a basic (pretty good!) image does seem to be quite doable.
reply