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

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 guess whatever display controller is in the SoC will help with some of that in some way. But it will still be quite complicated, because it's undocumented, and the driver is only available as a binary blob.