E-ink display

[grego]

Has anyone considered making an alternative version of PinePhone with an e-ink screen?
In 2020, with phones like Hisense A5 released, it should be possible. And also much nicer to have this device run fully on OSS, instead of some manufacturer bloatware that all the present options are full of.

I think a simple black and white screen would be sufficient. Also screen latency would not be that much of an issue, as long as the basic phone functionalities are usable.
I believe it would be a perfect device for people who want to maintain the ability to call or text someone via the mobile network or the internet and do some occasional web browsing or navigation, while minimising the distraction and eye strain of their phone and also the amount of adversarial software they run on their device. Heck, it could even be a decent e-reader!

For people more familiar with PinePhone hardware, what would need to be done to make some e-ink screen compatible? How much change in hardware (and software) would it entail? In case this idea gains any traction, I would be very happy to participate on developing the software and testing it out (although I acknowledge this is quite premature and might be more appropriate to say among developers of some particular OS).

Anyway, I'm very interested in your stance on this.
(Apologies if this is a wrong section to post this, will be glad to move it into a more appropriate one.)

[drpi]

A e-ink display requires a different hardware than a LCD display. You'd need a redesigned mother board to be able to use such a display.

[clover]

I'd just like to see a Pine64 eReader!

[grego]

A e-ink display requires a different hardware than a LCD display. You'd need a redesigned mother board to be able to use such a display.

Really? Why is it so?

[wibble]

A e-ink display requires a different hardware than a LCD display. You'd need a redesigned mother board to be able to use such a display.

Really? Why is it so?

Very different performance requirements - LCDs are getting a full refresh with full colour images many times a second. e-ink displays get occasional refreshes with low bit depth images, and an emphasis on low power consumption. The LCD gets a high bandwidth interface from a GPU while the e-ink displays usually use lower bandwidth, lower power consumption SPI.

[grego]

A e-ink display requires a different hardware than a LCD display. You'd need a redesigned mother board to be able to use such a display.

Really? Why is it so?

Very different performance requirements - LCDs are getting a full refresh with full colour images many times a second. e-ink displays get occasional refreshes with low bit depth images, and an emphasis on low power consumption. The LCD gets a high bandwidth interface from a GPU while the e-ink displays usually use lower bandwidth, lower power consumption SPI.

Oh that makes sense, I see.

[---]

A e-ink display requires a different hardware than a LCD display. You'd need a redesigned mother board to be able to use such a display.

Really? Why is it so?

Very different performance requirements - LCDs are getting a full refresh with full colour images many times a second. e-ink displays get occasional refreshes with low bit depth images, and an emphasis on low power consumption. The LCD gets a high bandwidth interface from a GPU while the e-ink displays usually use lower bandwidth, lower power consumption SPI.

Oh that makes sense, I see.

I would love to see an e-ink additional display option. I wonder what conversion would be required between the USB-c interface and the e-ink display?.

[wibble]

I would love to see an e-ink additional display option. I wonder what conversion would be required between the USB-c interface and the e-ink display?.

The better option is probably to use the I2C on the pogo pins to send some basic information to be shown to a small microcontroller, and have that microcontroller compose the graphics and send them to the e-ink display over SPI.

[---]

I would love to see an e-ink additional display option. I wonder what conversion would be required between the USB-c interface and the e-ink display?.

The better option is probably to use the I2C on the pogo pins to send some basic information to be shown to a small microcontroller, and have that microcontroller compose the graphics and send them to the e-ink display over SPI.

Good point, when I get my phone 'organized' I'll be looking into that option.

[drpi]

I would love to see an e-ink additional display option. I wonder what conversion would be required between the USB-c interface and the e-ink display?.

The better option is probably to use the I2C on the pogo pins to send some basic information to be shown to a small microcontroller, and have that microcontroller compose the graphics and send them to the e-ink display over SPI.

Good point, when I get my phone 'organized' I'll be looking into that option.

A better option is to use a FPGA instead of a micro-controller.
Why better ?
Because :
- The e-ink display has a non standard SPI interface. With a FPGA, this is not a problem. With a micro-controller, you have to write weird code.
- With some Lattice FPGAs, you can initialize/update the FPGA code through the I2C interface. No need to program the board with a specific tool.
- One program to maintain.