5 ms·

> 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 "wa

> 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/drivers/video/mxc/mxc_epdc_fb.c https://github.com/UDOOboard/Kernel_Unico/blob/master/driver... Could you share some citations or links to what specific thing you're referring to?

bayindirh 4y ago
I've briefly looked for the things I've read in the past but failed to find them currently. Will do when I return home, and will send another reply. I don't like when I can't find the references I remember so vividly.
russh 4y ago
https://github.com/vroland/epdiy/tree/master/src/epd_driver/waveforms https://github.com/vroland/epdiy/tree/master/src/epd_driver/...
- robinsoh 4y ago
  Please clarify what you are attempting to communicate with the link to the header file, otherwise it looks like you just googled and gave a link to something that you yourself don't really understand.
FullyFunctional 4y ago
It would be hard to miss as it’s required to display anything. However, most dev kits come with a controller which embeds a [proprietary] set of waveforms. That however leaves you with conservative implementations and far from state-of-the-art.
- robinsoh 4y ago
  > most dev kits come with a controller which embeds a [proprietary] set of waveforms. That however leaves you with conservative implementations and far from state-of-the-art. Please clarify what dev kits you are referring to. What do you mean state-of-the-art?
  - FullyFunctional 4y ago
    There's a lots of dev kits, but take for example https://shopkits.eink.com/product/ice-driving-board/ https://shopkits.eink.com/product/ice-driving-board/ 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.
    - robinsoh 4y ago
      > There's a lots of dev kits, but take for example https://shopkits.eink.com/product/ice-driving-board/ https://shopkits.eink.com/product/ice-driving-board/ Are you saying the ICE driving board hardcodes waveforms? Where do you see that stated?
      - FullyFunctional 4y ago
        I didn't say that, but I don't see the waveform they use documented and I didn't see it documented how to make your own and/or replace the one the dev kit is using. It seems you think I'm wrong, great! Please share how and why.
bayindirh 4y ago
So, I have looked around and refreshed what I've read, and what I've saw. Let me try to summarize. 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-declaration.pdf https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declara... [1]: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-c... [2]: https://www.eink.com/product.html?type=productdetail&id=1 https://www.eink.com/product.html?type=productdetail&id=1 [3]: https://hackaday.io/project/21168-fpga-eink-controller/log/57302-waveforms-table-introduction https://hackaday.io/project/21168-fpga-eink-controller/log/5...

bayindirh 4y ago

I've briefly looked for the things I've read in the past but failed to find them currently. Will do when I return home, and will send another reply. I don't like when I can't find the references I remember so vividly.

russh 4y ago

https://github.com/vroland/epdiy/tree/master/src/epd_driver/waveforms https://github.com/vroland/epdiy/tree/master/src/epd_driver/...

robinsoh 4y ago
Please clarify what you are attempting to communicate with the link to the header file, otherwise it looks like you just googled and gave a link to something that you yourself don't really understand.

FullyFunctional 4y ago

It would be hard to miss as it’s required to display anything. However, most dev kits come with a controller which embeds a [proprietary] set of waveforms. That however leaves you with conservative implementations and far from state-of-the-art.

robinsoh 4y ago
> most dev kits come with a controller which embeds a [proprietary] set of waveforms. That however leaves you with conservative implementations and far from state-of-the-art. Please clarify what dev kits you are referring to. What do you mean state-of-the-art?
- FullyFunctional 4y ago
  There's a lots of dev kits, but take for example https://shopkits.eink.com/product/ice-driving-board/ https://shopkits.eink.com/product/ice-driving-board/ 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.
  - robinsoh 4y ago
    > There's a lots of dev kits, but take for example https://shopkits.eink.com/product/ice-driving-board/ https://shopkits.eink.com/product/ice-driving-board/ Are you saying the ICE driving board hardcodes waveforms? Where do you see that stated?
    - FullyFunctional 4y ago
      I didn't say that, but I don't see the waveform they use documented and I didn't see it documented how to make your own and/or replace the one the dev kit is using. It seems you think I'm wrong, great! Please share how and why.

bayindirh 4y ago

So, I have looked around and refreshed what I've read, and what I've saw. Let me try to summarize. 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-declaration.pdf https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declara... [1]: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-c... [2]: https://www.eink.com/product.html?type=productdetail&id=1 https://www.eink.com/product.html?type=productdetail&id=1 [3]: https://hackaday.io/project/21168-fpga-eink-controller/log/57302-waveforms-table-introduction https://hackaday.io/project/21168-fpga-eink-controller/log/5...