On Fri, 2003-01-10 at 03:54, James Simmons wrote:
>
> > 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.
>
> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:32 EST