E-ink Screen
- Thread starter Kiga
- Start date
Tenka
Snakes and Fish
- Joined
- Jan 28, 2012
- Messages
- 701
Would it? I'm not informed enough yet, but I hoped there could be a very thick protective layer above it. I would also hope that this screen in theory could not look like a screen, or like anything was unusual at all while it was turned off.
God Ginrai
Godmaster
Actually, no it won't. They happen to have very rugged e-ink screens out there.
Right here, if you go to 22:35 in this video, one of the spokespeople for e-ink actually stomps on it and it continues working just fine:
https://www.youtube.com/embed/ajqiG_4tLcc?feature=oembedIt could. I want it whether it has touch or not. It is possible to get it working with capacitive touch technology.
-God Ginrai
Last edited by a moderator:
Tenka
Snakes and Fish
- Joined
- Jan 28, 2012
- Messages
- 701
At 8:25 in the video there is a crazy illusion, the top four rectangles in the large pixel display are moving all over, but the bottom four rectangles are not effected.
I see, these can be very durable and don't need protective layers at all. E-Ink displays are beginning to look more like regular image displays though, concerning the unused space on them, it appears to always be filled with something. I was hoping that unused space in an E-Ink display on the back of the screen could look exactly the same as the unpopulated Pyra case surface. It no longer sounds like the display can just be opaque where unused, but maybe the color displayed on it can be similar enough to the color of the rest of the case to fully disguise it. Does this sound possible?
I see, these can be very durable and don't need protective layers at all. E-Ink displays are beginning to look more like regular image displays though, concerning the unused space on them, it appears to always be filled with something. I was hoping that unused space in an E-Ink display on the back of the screen could look exactly the same as the unpopulated Pyra case surface. It no longer sounds like the display can just be opaque where unused, but maybe the color displayed on it can be similar enough to the color of the rest of the case to fully disguise it. Does this sound possible?
ekianjo
Hardcore Member
No, and QUalcomm just canned Mirasol apparently not too long ago because they could not manufacture it on a larger scale. That sucks, but we won't get color e-screens anytime soon.
God Ginrai
Godmaster
We would probably have a monochrome e-ink display, which would be just black or not black. So we could match the color of the case if the case was black. Also, we could possibly use that color overlay idea to shade the e-ink screen so it matches the case colors. I'm not sure it's worth it to add a color overlay, tho'.
Neat thought. Imagine plugging in the device and a charge indicator appears on the lid thanks to the e-ink screen.
-God Ginrai
Really? Man.We may not need them in the future anyway. Link
ekianjo
Hardcore Member
I wouldn't count on stuff like that anyway.
Gizmodo has zero credibility in predicting when stuff hits the market, and they completely fail to explain:
- the market issues
- the scalability issues
- the supply chain issues
inherited by all these new screen technologies.
And, by the way, they are only showing microscopic screens on these pics, which means they are nowhere ready to make bigger screens. Call me sceptic on this. There's always a revolution in technology every single week if you believe the papers, but the ones that make it on the market are very, very few.
ekianjo
Hardcore Member
But where would you connect this additional display ? on GPIO ports ?
One cool thing would be to have the LOGO of the Pyra displayed on this E-ink display
instead of being molded in the case.
Last edited by a moderator:
God Ginrai
Godmaster
IIRC, All the SoCs we've been looking at have support for up to 3 displays, so if one is routed to the main screen, and one is routed to HDMI, we should still have one display's pins that we can connect, right?
Exactly. The logo of the Pyra as the default, and then users can personalize it to display whatever they want later.One cool thing would be to have the LOGO of the Pyra displayed on this E-ink display
-God Ginrai
slaeshjag
¯\_(ツ)_/¯
E-ink is not exactly a high bandwidth application. You can probably get away with just slapping it onto the SPI-bus and nobody will notice. I don't think you even can use a normal display interface to drive an E-ink display.
ekianjo
Hardcore Member
Correct, they have specific interfaces. That's why I was mentioning GPIO.
slaeshjag
¯\_(ツ)_/¯
You preferably want to use a real databus from the SoC, even if it means you use GPIO on a µC to actually drive the display. Bit-banging a graphical display in a kernel driver is silly. Although I guess you could use one of the M4 cores in the OMAP for it...
God Ginrai
Godmaster
ekianjo
Hardcore Member
It's ok, we all learn new stuff everyday
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Unlike regular displays which need to be refreshed constantly, you'd only have to stream the screen when it updated, so it actually isn't all that bad of an idea to just use the CPU.
slaeshjag
¯\_(ツ)_/¯
It is, if you can't have the interface handled by the hardware.
An e-ink display will most likely not want a data clock as fast as you can flip a GPIO pin. Which means you have to wait a while before poking the GPIO pin. If you allow context switch while this happens, you'll get really, really, really slow data transfers, maybe minutes to transfer the framebuffer.
The alternative is to lock up the CPU for the duration of the data transfer. If the data bus is slow, that could be tens or hundreds of milliseconds.
It is silly to bit-bang a framebuffer with the CPU.
An e-ink display will most likely not want a data clock as fast as you can flip a GPIO pin. Which means you have to wait a while before poking the GPIO pin. If you allow context switch while this happens, you'll get really, really, really slow data transfers, maybe minutes to transfer the framebuffer.
The alternative is to lock up the CPU for the duration of the data transfer. If the data bus is slow, that could be tens or hundreds of milliseconds.
It is silly to bit-bang a framebuffer with the CPU.
Last edited by a moderator:
