On Fri, 2003-01-10 at 03:54, James Simmons wrote:

quoted

However, as Geert mentioned, if you want to support rotation
generically, then you have to do it in the fbcon level.  The driver need
not know if the display is rotated or not.  All it needs to do is fill a
region with color, color expand a bitmap and move blocks of data, and
optionally 'pan' the window.  Fbcon will pass the correct (ie, oriented)
information for the driver.

Yes. Hardware rotation shouldn't also not effect the way accel 
operatations are done.

 
The main difference is if the hardware supports rotation, fbcon will
present it with "normal" data.  With the generic implementation, fbcon
will present the driver with rotated data.

So we need a driver capabilities field either in fb_info or
fb_fix_screeninfo.

quoted

This will not be too processor intensive as long as some data is
prepared beforehand, like a rotated fontdata.

Yeap!! The only thing is we could end up with 4 times the amount of data.
 

Not really.  We can dynamically rotate the fontdata using the default
display->fontdata into another buffer.  I believe I have functions that
do that in the patch I submitted.  (Sorry, I lost it when one of my
drives crashed :-(.

Tony