4 ms·

I'm very interested in the possibility of reusing eink screens from old ereaders on the Quartz64? It seems like there is only the one brand, but probably there

I'm very interested in the possibility of reusing eink screens from old ereaders on the Quartz64? It seems like there is only the one brand, but probably there are generations of EDP ports or flavors relating to maximum size, color/gray-scale Levels, etc?

MayeulC 6y ago
I know nothing about this; is the connector and protocol standard and common to all eink devices?
- foolmeonce 6y ago
  All I've found is SoC makers have their own driver, but refer to the interface in terms of max resolutions, etc. I hope it is very similar to the situation with HDMI, where the interface doesn't vary, but alternatively, it could be a matter of proprietary things not being discussed clearly because of NDAs, etc.
- megous 6y ago
  It's not. There's all kinds of variety in the connector layouts and signalling. What's shared may be a general principle of driving these displays, but beware that to get the best results, you'll have to have a undocumneted format waveform file that differs per batch of the displays, you'll have to have a VCOM voltage that differs per panel and may or may not be written on the cable, and many other things. I had a lot of fun when after clearing the display and writing new image to it, the old image also faded in again into existence, which is apparently something that may happen if not everything is aligned correctly. There's a lot of hidden proprietary woodoo that you'll have to uncover to drive these displays correctly. There are some displays that hide this inside some controller and give you a nice SPI interface, but for maaany displays you'll just get a raw interface to the gate/source drivers + access to 5-6 different "high" voltage sinks and similar number of clocking/control signals that you have to drive precisely too (voltage/timing-wise at low 100's of ns level of precision), and the rest is up to you. Source: (doing a lot of reverse engineering to put mainline Linux and write a driver for some broken display PocketBooks I bought from auction site and repaired with replacement displays from China) https://linux-sunxi.org/PocketBook_Touch_Lux_3 https://linux-sunxi.org/PocketBook_Touch_Lux_3 Fun fact: vast majority of PocketBooks out there drive eInk displays by DMA driven bitbanging from a generic LCD controller, without any specialized eInk controller.
  - MayeulC 6y ago
    Thank you a lot for the answer, that's unfortunately more along the lines of what I was expecting. Good luck for your project, I have yet to dig into e-ink devices, but that's something on my radar. It's a shame the firmware of these devices is not open, I bet the community could improve it a whole lot. Also thank you again for your work on the Pinephone ;)
    - megous 6y ago
      I also forgot to mention that everything is temperature dependent, because ink particles move differently at different temperatures. ;) OTOH, if you don't mind full refresh (shaking the ink into uniform white by making the whole display black/white/black/white repeatedly a few times) between updates, these displays seem to be quite forgiving, in my limited experience. So it's not all doom and gloom. :)
      - MayeulC 6y ago
        Thanks for the insight! It's probably like everything else: make your proof-of-concept (full refresh) work, and refine the rest until you're sufficiently bothered to fix the full-refresh thing :D As a plus, this is likely the most portable way of driving these, voltage levels notwithstanding. I guess you also have "smart" and "dumb" screens, some that include temperature sensors, etc?
        megous 6y ago
        Temperature sensor can be just a NTC resistor on the cable leading to the display (for example). The program has to select the right "waveforms" for the current temperature. Waveform files have timings for various temperatures.

MayeulC 6y ago

I know nothing about this; is the connector and protocol standard and common to all eink devices?

foolmeonce 6y ago
All I've found is SoC makers have their own driver, but refer to the interface in terms of max resolutions, etc. I hope it is very similar to the situation with HDMI, where the interface doesn't vary, but alternatively, it could be a matter of proprietary things not being discussed clearly because of NDAs, etc.
megous 6y ago
It's not. There's all kinds of variety in the connector layouts and signalling. What's shared may be a general principle of driving these displays, but beware that to get the best results, you'll have to have a undocumneted format waveform file that differs per batch of the displays, you'll have to have a VCOM voltage that differs per panel and may or may not be written on the cable, and many other things. I had a lot of fun when after clearing the display and writing new image to it, the old image also faded in again into existence, which is apparently something that may happen if not everything is aligned correctly. There's a lot of hidden proprietary woodoo that you'll have to uncover to drive these displays correctly. There are some displays that hide this inside some controller and give you a nice SPI interface, but for maaany displays you'll just get a raw interface to the gate/source drivers + access to 5-6 different "high" voltage sinks and similar number of clocking/control signals that you have to drive precisely too (voltage/timing-wise at low 100's of ns level of precision), and the rest is up to you. Source: (doing a lot of reverse engineering to put mainline Linux and write a driver for some broken display PocketBooks I bought from auction site and repaired with replacement displays from China) https://linux-sunxi.org/PocketBook_Touch_Lux_3 https://linux-sunxi.org/PocketBook_Touch_Lux_3 Fun fact: vast majority of PocketBooks out there drive eInk displays by DMA driven bitbanging from a generic LCD controller, without any specialized eInk controller.
- MayeulC 6y ago
  Thank you a lot for the answer, that's unfortunately more along the lines of what I was expecting. Good luck for your project, I have yet to dig into e-ink devices, but that's something on my radar. It's a shame the firmware of these devices is not open, I bet the community could improve it a whole lot. Also thank you again for your work on the Pinephone ;)
  - megous 6y ago
    I also forgot to mention that everything is temperature dependent, because ink particles move differently at different temperatures. ;) OTOH, if you don't mind full refresh (shaking the ink into uniform white by making the whole display black/white/black/white repeatedly a few times) between updates, these displays seem to be quite forgiving, in my limited experience. So it's not all doom and gloom. :)
    - MayeulC 6y ago
      Thanks for the insight! It's probably like everything else: make your proof-of-concept (full refresh) work, and refine the rest until you're sufficiently bothered to fix the full-refresh thing :D As a plus, this is likely the most portable way of driving these, voltage levels notwithstanding. I guess you also have "smart" and "dumb" screens, some that include temperature sensors, etc?
      - megous 6y ago
        Temperature sensor can be just a NTC resistor on the cable leading to the display (for example). The program has to select the right "waveforms" for the current temperature. Waveform files have timings for various temperatures.