From: James Simmons <hidden> Date: 2003-01-07 22:36:12
I'm about to implement rotation which is needed for devices like the ipaq.
The question is do we flip the xres and yres values depending on the
rotation or do we just alter the data that will be drawn to make the
screen appear to rotate. How does hardware rotate view the x and y axis?
Are they rotated or does just the data get rotated?
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
I'm about to implement rotation which is needed for devices like the ipaq.
The question is do we flip the xres and yres values depending on the
rotation or do we just alter the data that will be drawn to make the
screen appear to rotate. How does hardware rotate view the x and y axis?
Are they rotated or does just the data get rotated?
Where are you going to implement the rotation? At the fbcon or fbdev level?
Fbcon has the advantage that it'll work for all frame buffer devices.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: Sven Luther <hidden> Date: 2003-01-08 10:44:09
On Wed, Jan 08, 2003 at 11:24:22AM +0100, Geert Uytterhoeven wrote:
On Tue, 7 Jan 2003, James Simmons wrote:
quoted
I'm about to implement rotation which is needed for devices like the ipaq.
The question is do we flip the xres and yres values depending on the
rotation or do we just alter the data that will be drawn to make the
screen appear to rotate. How does hardware rotate view the x and y axis?
Are they rotated or does just the data get rotated?
Where are you going to implement the rotation? At the fbcon or fbdev level?
Fbcon has the advantage that it'll work for all frame buffer devices.
But you could also provide driver hooks for the chips which have such a
rotation feature included (don't know if such exist, but i suppose they
do, or may in the future).
So, we also support fbcon for not left to righ locales ?
Friendly,
Sven Luther
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
I'm about to implement rotation which is needed for devices like the ipaq.
The question is do we flip the xres and yres values depending on the
rotation or do we just alter the data that will be drawn to make the
screen appear to rotate. How does hardware rotate view the x and y axis?
Are they rotated or does just the data get rotated?
If the graphics card has hardware support for rotation, then there is
nothing to be done. It's the job of the driver if it wants to rotate
the display or not. This is similar to video overlay mirroring. What
the user app sees is the framebuffer in "normal" orientation, but what
gets displayed is mirrored.
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.
This will not be too processor intensive as long as some data is
prepared beforehand, like a rotated fontdata.
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 submitted a patch before (see fbdev archives for "Console Rotation"
thread) that rotates the console this way. I had vga16fb, vesafb, and
i810fb rotate the display without any driver code change. Display
panning was also supported.
However, because we use mmap to expose the framebuffer memory, we will
not be able to completely support rotation for user applications. They
have to do it on their own.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: James Simmons <hidden> Date: 2003-01-09 19:35:37
Where are you going to implement the rotation? At the fbcon or fbdev level?
We already have a hook for hardware acceleration in struct fb_ops.
Fbcon has the advantage that it'll work for all frame buffer devices.
The fbdev level will have the functionalty but fbcon is the one that needs
it.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: James Simmons <hidden> Date: 2003-01-09 19:37:15
quoted
Fbcon has the advantage that it'll work for all frame buffer devices.
But you could also provide driver hooks for the chips which have such a
rotation feature included (don't know if such exist, but i suppose they
do, or may in the future).
Hooks already exist in struct fb_ops.
So, we also support fbcon for not left to righ locales ?
From: James Simmons <hidden> Date: 2003-01-09 19:45:45
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
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
From: James Simmons <hidden> Date: 2003-01-10 19:34:18
quoted
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.
We can just test if the rotation hook exist for the fbdev driver. No hook
then use generic code in fbcon. Also we have a angle field in var so we
can see if the user wants the data rotated.
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 :-(.
I have that patch. It just has to be updated to the latest changes.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
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.
We can just test if the rotation hook exist for the fbdev driver. No hook
Okay. What will the hook do, BTW? Just turn hardware rotation to
the appropriate orientation? Something like...
int fb_rotate(struct fb_info *info, int rotate);
Then we can do something like:
if (info->fbops->fb_rotate) {
info->fbops->fb_rotate(info, FB_ROTATE_CCW);
"pass 'normally' oriented data"
else
"pass data rotated CCW"
}
Also, you may want to place the rotate field in fb_fix_screeninfo
instead. You mentioned that rotation is to be activated at the console
layer, so the rotate field is for informational purposes only.
then use generic code in fbcon. Also we have a angle field in var so we
can see if the user wants the data rotated.
quoted
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 :-(.
I have that patch. It just has to be updated to the latest changes.
Yeap. Geert forwarded them to me. Thanks Geert :-)
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com