View Single Post
Old 06-10-2011, 02:57 PM   #30
mark03
Enthusiast
mark03 began at the beginning.
 
Posts: 28
Karma: 10
Join Date: Jun 2011
Device: Kindle 3 wifi
Quote:
Originally Posted by hawhill View Post
I've attached the code I've written as a gfxdriver for Qt embedded. Grep for the ioctls. But note that I'm only using a single one of them: the fast (but a bit dirty) refresh of rectangular areas. The driver in the kernel seems to be a bit more sophisticated but I didn't come across other code that uses it yet.
Thanks! I know next to nothing about Qt but it's most helpful to see a concrete example.

I've been looking through Jaya Kumar's old Linux/eink presentations and trying to figure out how "deferred I/O" plays into this. There is an interesting comment in the Amazon kernel sources, next to the deferred i/o stuff:

static void einkfb_deferred_io(struct fb_info *info, struct list_head *pagelist)
{
// At the moment, we're just using the deferred I/O mechanism to map in
// pages for us. We're not using it to update the display with since
// we have our own, more direct method for doing that.
}

static struct fb_deferred_io einkfb_defio =
{
.delay = HZ,
.deferred_io = einkfb_deferred_io,
};


It would be nice to know exactly how their "own, more direct method'" works in practice. Is it just user apps calling ioctls at the appropriate times, or do they have something else in the directfb layer?

BTW, I managed to find a presentation with some details of the various eink update types, on Baidu of all places:

http://wenku.baidu.com/view/187d5395...5f465e245.html

There is some good discussion of the tradeoff between non-flashing (fast but limited to black and white, and susceptible to ghosting) and flashing (slower but allows all grayscales and not susceptible to ghosting) updates. I think it is specific to the older (pre-Pearl) panel but probably still relevant.
mark03 is offline   Reply With Quote