Re: [PATCH] radeonfb(): memmove() fix -- this one works ;-)

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

On Wed, 2004-04-21 at 08:52, James Simmons wrote:
> > BTW, James, did we decide what is the best way to set fbcon accel
> > mode ? For drivers with copyarea accelerated, we want YMOVE. I'd like
> > a patch to send Linus/Andrew asap along with some pending radeonfb
> > fixes for that.
> 
> I had to do some thinking about this. Here is explation ofthe scrolling 
> code. It really needs to be cleaned up. So renamings would make sense 
> here.

> .../...

Why not simply

 1) Document properly what those various options do
 2) Let the driver provide it's "preferred" scroll mode ? It's sort-of
    a stack violation since it really only affects fbcon at this point,
    but since it's just an "hint", it's perfectly acceptable.

(Note: I'm not sure about controlfb at this point, I have to dig
out some old HW and test)

Also, we sort-of lost the ability to have fbcon specific accels in the
drivers... It would have been nice to be able to store the font in
vram and use blits to composite text, but that would have meant having
fbcon-related hooks =P Or maybe we can find a clean way to express that
to fbcon without clobbering fbdev's with fbcon-related datas ? Simply by
having fbcon request a vres big enough to store the font data outside
of the visible area and using copyarea ?

Ben.

> In the original code we had:
> 
> These we set by the driver.
> 
> SCROLL_YREDRAW		( __SCROLL_YFIXED  | __SCROLL_YREDRAW )     Lots use this
> SCROLL_YNOMOVE		( __SCROLL_YNOMOVE | __SCROLL_YPANREDRAW )  Lots use this
> SCROLL_YNOPARTIAL	  __SCROLL_YNOPARTIAL			    (controlfb)
> 
> fbcon.c -> updatescrollmode.
> 
> __SCROLL_YFIXED		--> Does not update. Test to see if it is set then exits
> __SCROLL_YWRAP		--> sets if we have ywrapstep and conditions are right
> __SCROLL_YPAN		--> sets if we have ypanstep and conditions are right
> __SCROLL_YNOMOVE	--> test for this and if yes then
> __SCROLL_YREDRAW	-->			set __SCROLL_YREDRAW
> __SCROLL_YMOVE		-->		      else set __SCROLL_YMOVE
> 
> __SCROLL_YMASK		Mask to clear out extra bits.
> 
> Not used in updatescrollmode
> 
> __SCROLL_YPANREDRAW	--> Set by SCROLL_YNOMOVE
> __SCROLL_YNOPARTIAL	--> Set by SCROLL_YNOPARTIAL. Its deals for the case 
> 			    when we can only only pan the whole screen, 
> 			    not a region of the screen.
> ---------------------------------------------------------------------------------
> Let go over what happened in the old code.
> 
> So if the driver set SCROLL_YNOPARTIAL then __SCROLL_YNOPARTIAL was set. This was
> to deal with hardware panning flickering. Only the controlfb used it. Is this 
> problem still present? If not this could go away. The goal is:
> 
> 	Handle screen flickering.
> 
> The second one is the driver using SCROLL_YREDRAW. This sets __SCROLL_YFIXED and
> __SCROLL_YREDRAW. When going into updatescrollmode nothing happens since the first
> thing we do is test for __SCROLL_YFIXED. So the goal is to override the hardware 
> panning or wrap. The system is set up to only __SCROLL_YREDRAW which just redraws
> all the font images. In this case only __SCROLL_YREDRAW is important. So the 
> goal is:
> 	
> 	if driver set SCROLL_YREDRAW
> 		Use hardware image drawing	// Only use this
> 
> The 3rd and final one is where we set the scrollmode to __SCROLL_YNOMOVE and 
> __SCROLL_YPANREDRAW. __SCROLL_YNOMOVE again is one of those variables used only
> in updatescrollmode. First we test to see if hardware panning or hardware wrapping. 
> Use that. If we don't have that ablity then we test the __SCROLL_YNOMOVE to see
> if we just draw all the font images or use a copyarea operation with the flag 
> is set to __SCROLL_YMOVE. So the goal is:
> 
> 	if Ywrap
> 		Use hardware ywrap
> 	else if ypan 
> 	  	Use hardware panning
> 	else if driver set SCROLL_YNOMOVE
> 		Use hardware image drawing
> 	else 
> 		Use hardware copyarea
> 
> I like to see this cleaned up now. The question is what is the proper order of all
> this stuff. For use we have the following conditions.
> 
> Hardware panning. Test for fb_pan_display and ypanstep. 
> Hardware wrapping. Test for ywrapstep.
> Hardware copyarea.
> Hardware image drawing.
> 
>    So if the we have the case of both copyarea and imageblit hardware accelerated we
> need to use copyarea for scrolling since that will be faster. Its the same case
> for if we only have copyarea accelerating. 
>    The question is if we have only hardware imageblit should we use that? There is
> a cost to assembly a image for the hardware to draw. The question is the assembly
> of the image less costly than a soft copyarea?
>    As for hardware panning should we prefer it above everthing? 
>    



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