Kernel_Unico

> The methods or refreshing e-ink displays are called "Wave Functions" in e-ink parlance, and they're actually implemented in software. I've never heard of "wave functions" in the context of electrophoretic displays nor have I ever seen a widely used commercial e-ink controller implement a software update method. Do you mean waveform table? All of them that I've seen in commercial use rely on hardware updates to perform the waveform table processing. Eg: here's the software used to setup the hardware used on most ebook readers: https://github.com/UDOOboard/Kernel_Unico/blob/master/driver... Could you share some citations or links to what specific thing you're referring to?

> They've figured out all the difficult stuff about e-ink They meaning Remarkable? If so, then that's marketing-speak. The simple truth is that Remarkable's products all use NXP (formerly Freescale) controllers. The Remarkable2 uses i.mx7D. That has a built-in hardware EPDC. You can google it. The driver is open source. https://github.com/UDOOboard/Kernel_Unico/blob/master/driver... That's what does all the "difficult stuff". Not Remarkable. > did you know that to flip pixels, e-ink displays require annoyingly proprietary lookup tables of waveforms that can be up to 5-dimensional? Yes. But you realize tables are each panel specific. Meaning every single panel you see requires a custom waveform. Nowadays they (E Ink and their partners)'re getting better and have some increased level of consistency so some waveforms can achieve the same res

> From what I've seen working on an e-reader, > f you want to use the nice partial refresh waveform, the open source aspect of this is going to run face first into secrecy requirements. The company selling you the display controller may be willing to build you an out of tree kernel module, and you can totally figure out what it does, but it won't be open source at that point. I'm sorry but you're making rather clearly incorrect statements which makes me suspicious of the veracity of your other comments. I'm quite familiar with their current and past technologies. You used the term "Partial refresh waveform". First of all, E Ink's active matrix electrophoretic displays like the ones in the Kindle don't need to be refreshed. That's a fundamental property. Secondly, in case you meant "partial update", that's a property of the display control

> the most challenging bits to liberate will be the EPDC firmware Could you clarify exactly what you mean by "EPDC firmware"? afaik, it is already published so what needs to be "liberated"? The devices you're talking about, eg: on your github, are the i.mx series of SoCs have an on-chip EPDC which is open source (the datasheets show all the registers) and the driver is also GPL. Eg: https://github.com/UDOOboard/Kernel_Unico/blob/master/driver... In case you mean the .fw file used in that driver, that's a misnomer. There is no CPU inside the EPDC. That .fw file is a plain voltage waveform file that defines voltage vs time waveforms to get pixels to appropriate graylevels. "Liberating" that would be akin to "liberating" the content of a .wav file. ie: just use hexdump -C.