|
Besides putting the right pixel data into the framebuffer - as in a memory area where pixel data is stored - the e-ink display must be triggered to refresh. It's not constantly refreshing as you would expect from other framebuffer based graphics output. As it's e-ink and a refresh is expensive in both power and time, you must have some logic that will refresh only when needed and maybe only what's needed.
The e-ink display has a controller that might
- do refreshes of rectangular areas in "fast" refresh mode (as done for cursors and the dictionary and menu pop-ups in the original software),
- and do refreshes of the full screen contents in "slow" mode (as done for page changes in the original software).
So you have to implement a refresh policy into software that just writes to the framebuffer and expects to be done.
As I have started experimenting with this myself (I have written - just another - Qt embedded video driver for the e-ink display), I can tell that there's software for which it's very hard to lay out a proper code path since you must often introduce differentiation between different graphical changes.
The most easiest approach is to introduce a simple "when it changes, refresh" policy. I think there was a "hack" floating somewhere in this forum that enables the X framebuffer server to do just this. In most cases, however, this is just to basic since in fact one perceived "display change" consists of a multitude of atomic changes.
Next iteration is to do "when it changes, wait a bit, and if there aren't any new changes, refresh". That's nice and all (and this is what I have done for Qt embedded), but it introduces new latency. You've got to get intimate with the application's program logic to really find the right moment to refresh. Just watching over framebuffer changes is expensive in both time or number-of-refreshes dimensions.
|