I work in the display industry. I've never heard anything like what you describe, except on HN comments and blogs that use HN comments as citations. Look at my comment history. I think your claim is false because everytime I've challenged a claim like yours the poster has never been able to substantiate it, but I keep an open mind, if you can provide some real citations backing your claim then I'm happy to be corrected.
There are lots of patents on electrophoretic displays.[1] And unlike some other industries, these patents are actually used in lawsuits by some players [2]. And anonymous insiders suggest that litigation and threats of litigation, together with enforced secrecy agreements really shape the industry [3].
[1]: https://scholar.google.com/scholar?q=electrophoretic+display...
[2]: https://www.bloomberg.com/press-releases/2017-12-20/e-ink-su...
Both Dasung and Onyx have been able to bring e-ink monitors using their technologies to market so if there's a significant barrier, it's not apparent.
There are lots of patents on software.
Could you explain your point in greater detail?
> And unlike some other industries, these patents are actually used in lawsuits by some players
I'm not able to follow. I work in the display industry. What lawsuits are you referencing? What players? How is it any different than the software industry? Anonymous insiders? You mean one HN post that appears nonsensical to a display industry insider who commented on that post and said it sounds like sour grapes from a guy who bought a few displays from Samsung LCD and expects Samsung to give him commercial pricing terms and special support and handholding for his startup?
However, somehow they're so closely guarded, and even if you have top of the line e-ink reader, it might not come with a license for a nice Wave Function which refreshes your display very nicely. For example, one of the most attractive features of Kindles is they use the best Wave Functions available for their displays (they may even licensed it exclusively) which refreshes the screens instantly and smoothly. My Kobo, while using the same screen, has more clunky refreshing modes built in.
Moreover, it seems, not all methods are provided on every CPU architecture, and you can't see the code of these things.
Lastly, these methods are probably improved upon and re-patented to keep the barrier for entry pretty high. New screens are definitely developed with more features, and they need new Wave Functions to work as expected.
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?
Please clarify what dev kits you are referring to. What do you mean state-of-the-art?
State of the art (at least a two years ago): Dasung Paperlike HD-F and reMarkable 2.
You'll not get the performance the those two with a dev kit like the one I linked.
Disclaimer: owns too many eInk devices (including Dasung Paperlike HD-F and the truly reMarkable 2), but haven't implemented any of this myself.
Are you saying the ICE driving board hardcodes waveforms? Where do you see that stated?
It seems you think I'm wrong, great! Please share how and why.
In short, the controller you are referring to as defines what you can send to the screen and what not, in other words, it gives you a capability ceiling, but the capability is not inside the controller. In your words, it defines the capability maximum for "waveform table processing".
On the other hand, the controllers you have are sitting ducks without these waveforms (which my mind conventionally renamed them to wave functions, well because they're waves, and they're defined as functions, and my brain is all hazy because everything I read, sorry about that).
These waveforms allows us to reach from a state to a state, generally in page scope, so you generally refresh the page completely. I understand that partial refreshes are also possible, but I don't know how they're implemented, exactly. My Kobo does it rather elegantly, but it might be pushing whole-screen updates too. Anyways.
[0] contains a PDF file which details how to process a waveform table, probably sold as a part of a screen by Waveshare. It details how to interpret the file, and how to make use of the data in the flash file, and drive the screen in most efficient/correct manner. It details gray levels, some special functions for maximizing blackness, etc.
[1] contains the article which brought me to the entrance of the rabbit hole. They give the basic details how they're software defined and controller can use many available waveforms, and you need to license them separately from the controller itself.
[2] is a product page for an eInk display, and it briefly mentions that the image quality you can get it both dependent on the controller and the waveform file you gonna get.
At the end of the day, yes you gonna need a panel controller to talk to your display properly, but what you can do and can't do with it is codified inside the waveform file you get with your device, and it's decoupled from the controller itself.
I guess it's possible that the controller you have can be too primitive to interpret or execute the waveform you have at hand, but vice versa is possible. i.e. your waveform is more primitive than the controller's capability ceiling, and despite having the best controller, you can't get most of the both your controller and your screen.
As a last note, [3] contains a reverse engineering effort and project for these waveforms, which I was not aware of before.
[0]: https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declara...
[1]: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-c...
[2]: https://www.eink.com/product.html?type=productdetail&id=1
[3]: https://hackaday.io/project/21168-fpga-eink-controller/log/5...