rotation.

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: Re: rotation.

[Sven Luther]

On Wed, Jan 08, 2003 at 11:24:22AM +0100, Geert Uytterhoeven wrote:
> 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.

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

Re: [Linux-fbdev-devel] Re: rotation.

[Måns Rullgård]

Sven Luther <luther@dpt-info.u-strasbg.fr> writes:

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

I heard of someone have problems with the display getting rotated in
Windows.  I don't know what chip it was.

-- 
Måns Rullgård
mru@users.sf.net

Re: Re: rotation.

[John Bradford]

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

It would be nice to have an option to be able to do the rotation
entirely in software - some desktop users might prefer to have a
portait-orientated display, when their graphics card doesn't have any
hardware rotation facilities at all.

John.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Re: rotation.

[Sven Luther]

On Wed, Jan 08, 2003 at 12:05:48PM +0000, John Bradford 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.
> > > 
> > > 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).
> 
> It would be nice to have an option to be able to do the rotation
> entirely in software - some desktop users might prefer to have a
> portait-orientated display, when their graphics card doesn't have any
> hardware rotation facilities at all.

Well, that is James plan. I suppose that for hardware that can do
hardware rotation, it will be faster to do it instead of having the
software do it though, and thus it would be nice to have a driver hook
or something.

This way, if rotation is asked, then if the driver supports hardware
rotation, do it, and if not, do it in software.

At first, no driver will support hardware rotation anyway, so it would
be done in software.

And then, you reuse the same stuff to drive a chinese console or
something such.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [Linux-fbdev-devel] Re: rotation.

[James Simmons]

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

That will happen in the core console code.

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

Re: [Linux-fbdev-devel] rotation.

[James Simmons]

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

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

[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