Re: [RFC 2.6.28 1/2] fbdev: add ability to set damage

["Magnus Damm" <magnus.damm@gmail.com>]

Hi Jaya,

I agree with Tomi about the memory allocation.

On Thu, Jan 15, 2009 at 6:53 PM, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
> Acknowledging that kzalloc is definitely not appropriate for all
> drivers, I propose the following changes to the implementation.
>
> a) allow userspace to determine optimal number of rectangles
> FBIO_GETDAMAGE
> which would allow the driver to report back (in the same fb_damage
> structure) the optimal number of rectangles that it can support.
>
> b) allow drivers to handle memory allocation as desired themselves
> Instead of doing the copy_from_user and kzalloc in the higher level
> fb_set_damage, we pass that user pointer directly to the driver. Thus,
> it would be:
> int (*fb_set_damage)(struct fb_info *info, struct fb_damage_user *damage);
>
> and the driver can handle according to its needs.

I wonder how fine grained control that is needed. It's not an exact
science, right? If a slightly larger area is updated than what is
needed then we will take a performance hit, but things should work as
expected apart from that right?

I'm a big fan of simple things like bitmaps. I wonder if it's a good
idea to divide the entire frame buffer into equally sized X*Y tiles
and have a bitmap of dirty bits. A "1" in the bitmap means tile is
dirty and needs update and a "0" means no need to update. The best
tile size is application specific. The size of the bitmap varies of
course with the tile size.

For a 1024x768 display using 32x32 tiles we need 24 32-bit words.
That's pretty small and simple, no?

Cheers,

/ magnus

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword