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

I agree. I don't doubt that in time we will find that the low level driver 
has to deal with this. Also it would really nice if userland new which is 
better for when it would using the accel engine.

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 ?

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.



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