| |||||||||||||
Supporting electronic paperSupporting electronic paperPosted Nov 22, 2007 7:47 UTC (Thu) by oak (subscriber, #2786)In reply to: Supporting electronic paper by nettings Parent article: Supporting electronic paper
GUADEC 2007 had a presentation of problems related to E-ink displays. The kernel display updating is not the only problem. It taking ~1 sec has also interesting implications for UI elements, for example scrollbars are pretty useless, see: http://guadec.org/node/636 Robert Love recently reviewed Amazon's Kindle (E-book reader with E-ink display), see: http://blog.rlove.org/2007_11_01_archive.html
(Log in to post comments)
Supporting electronic paper Posted Nov 22, 2007 10:38 UTC (Thu) by jayakumar (guest, #49119) [Link] > The kernel display updating is not the only problem. It taking ~1 sec has > also interesting implications for UI elements, for example scrollbars are Yes, I agree with you that traditional UI components such as sliders are impacted by the high latency of the display media. But you mention "kernel display updating" which is something that I am not sure I understand. I would like to clarify that I didn't write about fbcon or in-kernel fbdev usage. Deferred IO drivers expose a 0-additional latency fb to all fbdev clients, especially clients like Xfbdev. This technique allows standard X11 apps like xpdf, etc that run on top of Xfbdev or other fbdev servers to use an E-Ink display without knowing about the high latency or having to control their draws. Let's say that the xclock (think of it as a rotating slider) ticks every 10ms and then calls XDraw*. The display could have 1s latency but deferred IO makes it such that the clock is never more than 1s behind the current time because it shows the most recent state rather than showing every one of each of the 10ms updates. I hope I'm explaining this well. If not, there's a youtube video that I've posted of an older version of metronomefb. http://www.youtube.com/watch?v=Or3R3Q8oyuE
|
|||||||||||||