rotation

rotation

[Hinko Kocevar]

Hello,

We have a 320x240 color TFT LCD display attached to EPSON s1d13706 chip. Currently the display does not need rotating, but with the new LCD panel that replaced the old one a rotation of 180 degrees needs to be applied. We have our own framebuffer driver - similar to drivers/video/s1d13xxxfb.c but with some additional stuff for our architecture (cris).

The question arises where is the best place to implement this rotation?

I reckon it is the kernel, since all userspace need to use framebuffer transparently.
We don't use the fbcon at all so fbcon rotation is not an option. I've spotted fb_rotate field in struct fb_ops with the deprecated comment (seen in skeletonfb.c). I guess this is not an option too..

Then I guess I'm left with (re-)implementing the fb_mmap/fb_read/fb_write/fb_fillrect/fb_copyarea/fb_imageblit ?!?!

Any comments?

Best regards,
Hinko

-- 
ÈETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: [Linux-fbdev-devel] rotation.

[Antonino Daplas]

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

Re: rotation.

[James Simmons]

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

Re: rotation.

[Antonino Daplas]

On Sat, 2003-01-11 at 03:42, James Simmons wrote:
> 
> > > 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.
> 
> > 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

rotation.

[James Simmons]

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

Re: rotation.

[Geert Uytterhoeven]

On Tue, 7 Jan 2003, James Simmons wrote:
> 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

Re: rotation.

[James Simmons]

> 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

Re: rotation.

[Antonino Daplas]

On Wed, 2003-01-08 at 06:44, James Simmons wrote:
> 
> 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