> 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 result on whole batches of panels. But you'll still see it being batch specific. Take a waveform for one batch and try to use it on another and you'll get lousy ghosty results or maybe even damage the panel permanently.
> and worked with E-ink directly to implement said waveform table, very low-latency partial updates, and other e-ink "secrets" that could very well be worked out via reverse engineering but are otherwise under NDA.
That's more marketing speak. If you look at their code which they published, https://github.com/remarkable , it is just minor patches to NXP's driver. All the hard work was done by NXP.
I suppose instead of "difficult stuff" what I should have said is "they signed E Ink's NDA and thus have access to whatever tool they use to generate waveforms, panel-specific or no." I don't mean to heap credit on Remarkable, it's just they're a Real Company™ who E Ink will talk to, and I am not. Frankly I consider getting a waveform that doesn't look bad or cause burn-in over time a more difficult achievement than an open source driver or a hardware e-ink driver (indeed, lots of SoCs have them). Hence '"secrets" that could very well be worked out via reverse engineering but are otherwise under NDA.'
> The driver is open source.
Clearly, or I couldn't be running Linux-libre with it.
> they signed E Ink's NDA and thus have access to whatever tool they use to generate waveforms, panel-specific or no
why would you think this? Remarkable doesn't generate waveforms and have never claimed that they do.
> it's just they're a Real Company™ who E Ink will talk to, and I am not
You say that as if it is unique to E Ink. Whereas its standard across the entire display industry. Do you think Samsung would talk to you? Do you think LG would talk to you? You have to be, in your words, a real company, someone that offers some value proposition. In fact, thinking about it, that's true throughout the entire tech industry. Nobody talks to someone who isn't going to offer some current or future profit.
I don't know, I probably think a lot of things that are wrong. Up until your last post I assumed the waveforms were provided by E Ink themselves. When you mentioned different panels needing different waveforms I assumed you must have meant per unit, not per model of display, because the latter is obvious. If they were unique per individual display that calibration would need to be done in the factory. Did I misunderstand, and you meant per model of display, and not per unit?
Come to think of this, I can verify this right now. Here are the results of `sha256sum /var/lib/uboot/waveform.bin` on two different Remarkable devices of the same model/SKU:
You'll have to take my word I didn't copy the same line twice... but as you can see, they're the same. So I don't necessarily think the waveforms are different per unit or batch.
> You say that as if it is unique to E Ink. Whereas its standard across the entire display industry.
Sure. But I was talking about why I bought a Remarkable instead of building an open source e-ink laptop--certainly not a product with volumes high enough to get any manufacturer to pay attention. Obviously I would have the same problem if I were trying to build a regular laptop with an LCD screen (or modern CPU, or WiFi...). For hobbyist projects you're certainly not getting any support from manufacturers. The best one can hope for is open datasheets/manuals and even that is pretty rare...
> You'll have to take my word I didn't copy the same line twice... but as you can see, they're the same. So I don't necessarily think the waveforms are different per unit or batch.
I believe you. Maybe they've solved said problems and now have waveforms that work reliably across multiple batches.
But looking at Kindle, you can see there's a different wbf for each panel batch.
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 result on whole batches of panels. But you'll still see it being batch specific. Take a waveform for one batch and try to use it on another and you'll get lousy ghosty results or maybe even damage the panel permanently.
> and worked with E-ink directly to implement said waveform table, very low-latency partial updates, and other e-ink "secrets" that could very well be worked out via reverse engineering but are otherwise under NDA.
That's more marketing speak. If you look at their code which they published, https://github.com/remarkable , it is just minor patches to NXP's driver. All the hard work was done by NXP.