Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver

2007-02-28 Thread James Simmons
> I'm not sure I understand. What the current implementation does is to > use host based framebuffer memory. Apps mmap that memory and draw to > that. Then after the delay, that framebuffer is written to the > device's memory. That's the scenario for hecubafb where the Apollo > controller maintain

Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver

2007-02-21 Thread Jaya Kumar
On 2/21/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote: > > You are right. I will need that. I could put that into struct > fb_deferred_io. So drivers would setup like: > Is it also possible to let the drivers do the 'deferred_io' themselves

Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver

2007-02-21 Thread Antonino A. Daplas
On Wed, 2007-02-21 at 11:55 -0500, Jaya Kumar wrote: > On 2/20/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > > Don't you need a way to specify the maximum deferral time? E.g. a field in > > fb_info. > > > > You are right. I will need that. I could put that into struct > fb_deferred_io. So d

Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver

2007-02-21 Thread Antonino A. Daplas
On Mon, 2007-02-19 at 23:13 -0500, Jaya Kumar wrote: > On 2/18/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > Given that, this would have to be something that's dealt with at the > > subsystem level rather than in individual drivers, hence the desire to > > see something like this more generically