> 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
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds