> 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.
> 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.
> The main difficulty with this approach is how do you tell the console to
> rotate the display? We cannot use fbset because the changes will not be
> visible to fbcon.
I think it should video fbcon=rotate:90 command line for example.
> I submitted a patch before (see fbdev archives for "Console Rotation"
> thread) that rotates the console this way. I had vga16fb, vesafb, and
I seen it and even have it still.
-
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:29 EST