Hi Jaya,

I agree with Tomi about the memory allocation.

On Thu, Jan 15, 2009 at 6:53 PM, Jaya Kumar [off-list ref] 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