Re: fb_write change in your tree

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Look again. The idea was to grab the userland data and create struct 
> fb_image then use xxxfb_imageblit to draw for you. We should never 
> allow fb_write and fb_read to directly access the framebuffer.

Right. Note that fb_read is still using copy_to_user() with the
fb as a source, and that is hairy too.

But I would still like to allow the fb to just overwrite the whole
fb_read/write implementation. Also, your patch may break things if
userland did fb_write for an amount that covers several lines but
ends up in a middle of one afaik, it converts to images that are
rectangles, and doesn't properly deal with the possible first line
and last lines not beeing complete

> Speaking of. We really need to cleanup the fb_write and crap.
> The program flow should be:
> 
> fb_write -> xxxfb_imageblit -> fb_pixmap.outbuf();
> 
> The outbuf and inbuf commands should replace the fb_writeX and fb_readX 
> stuff. This way driver developers can still use the cfb_xxx functions for 
> strange hardware. a good example is the Epson 1335 chip. You can only 
> access the framebuffer 16 bits at a time. Using 32 bit transfers will drop 
> have the data. Why epson did this will never be know.
> 
>    The other bonus with using the imageblit method with fb_write is 
> that we can treat planar modes a packed pixel modes :-)
> 
> 
> 
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
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