Struct fb_pixmap. We have data pointer *addr. The only problem is using 
the memory space to the right of the visible framebuffer

------------|
|	|   |
|	|   |
--------------

At the bottom of the framebuffer it would be no problem. We could even use 
struct fb_pixmap with texture maps. Store fonts as texture maps and just 
draw them to a surface. You can do lots of fancy tricks. The only issue I 
have thought about is we might need to had a hook for fb_get_buffer_offset.
Not to big a deal.

The choice of where to allocate that pixmap may not be trivial. It would
be interesting to have a call to the fbdev to deal with that. If we call
this pixmap the "work area" for example (or whatever fancy name you can
find), we could have a call "prepare_work_area" to the fbdev, giving it
the size requested by the client (based on the font size).

That should stay optional as it's not interesting for drivers without a
fast copyarea of course.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click