linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* rotation.
@ 2003-01-07 22:44 James Simmons
  2003-01-08 10:24 ` rotation Geert Uytterhoeven
  2003-01-08 16:56 ` rotation Antonino Daplas
  0 siblings, 2 replies; 7+ messages in thread
From: James Simmons @ 2003-01-07 22:44 UTC (permalink / raw)
  To: Linux Fbdev development list
  Cc: Linux Kernel Mailing List, Geert Uytterhoeven


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: rotation.
  2003-01-07 22:44 rotation James Simmons
@ 2003-01-08 10:24 ` Geert Uytterhoeven
  2003-01-09 19:44   ` rotation James Simmons
  2003-01-08 16:56 ` rotation Antonino Daplas
  1 sibling, 1 reply; 7+ messages in thread
From: Geert Uytterhoeven @ 2003-01-08 10:24 UTC (permalink / raw)
  To: James Simmons; +Cc: Linux Fbdev development list, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: rotation.
  2003-01-07 22:44 rotation James Simmons
  2003-01-08 10:24 ` rotation Geert Uytterhoeven
@ 2003-01-08 16:56 ` Antonino Daplas
  1 sibling, 0 replies; 7+ messages in thread
From: Antonino Daplas @ 2003-01-08 16:56 UTC (permalink / raw)
  To: James Simmons
  Cc: Linux Fbdev development list, Linux Kernel Mailing List,
	Geert Uytterhoeven

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: rotation.
  2003-01-08 10:24 ` rotation Geert Uytterhoeven
@ 2003-01-09 19:44   ` James Simmons
  0 siblings, 0 replies; 7+ messages in thread
From: James Simmons @ 2003-01-09 19:44 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linux Fbdev development list, Linux Kernel Mailing List


> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: rotation.
  2003-01-10 10:26 [Linux-fbdev-devel] rotation Antonino Daplas
@ 2003-01-10 19:42 ` James Simmons
  2003-01-11  5:13   ` rotation Antonino Daplas
  0 siblings, 1 reply; 7+ messages in thread
From: James Simmons @ 2003-01-10 19:42 UTC (permalink / raw)
  To: Antonino Daplas
  Cc: Linux Fbdev development list, Linux Kernel Mailing List,
	Geert Uytterhoeven


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: rotation.
  2003-01-10 19:42 ` rotation James Simmons
@ 2003-01-11  5:13   ` Antonino Daplas
  0 siblings, 0 replies; 7+ messages in thread
From: Antonino Daplas @ 2003-01-11  5:13 UTC (permalink / raw)
  To: James Simmons
  Cc: Linux Fbdev development list, Linux Kernel Mailing List,
	Geert Uytterhoeven

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* rotation
@ 2008-07-01 10:26 Hinko Kocevar
  0 siblings, 0 replies; 7+ messages in thread
From: Hinko Kocevar @ 2008-07-01 10:26 UTC (permalink / raw)
  To: linux-fbdev-devel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-07-01 10:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-01 10:26 rotation Hinko Kocevar
  -- strict thread matches above, loose matches on Subject: below --
2003-01-10 10:26 [Linux-fbdev-devel] rotation Antonino Daplas
2003-01-10 19:42 ` rotation James Simmons
2003-01-11  5:13   ` rotation Antonino Daplas
2003-01-07 22:44 rotation James Simmons
2003-01-08 10:24 ` rotation Geert Uytterhoeven
2003-01-09 19:44   ` rotation James Simmons
2003-01-08 16:56 ` rotation Antonino Daplas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).