Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@in...> - 2003-01-07 22:45:56
|
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? |
|
From: Geert U. <ge...@li...> - 2003-01-08 10:26:11
|
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 -- ge...@li...
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
|
|
From: Sven L. <lu...@dp...> - 2003-01-08 10:52:44
|
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 |
|
From: James S. <jsi...@in...> - 2003-01-09 19:47:04
|
> > 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. |
|
From: James S. <jsi...@in...> - 2003-01-09 19:45:26
|
> 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. |
|
From: <mr...@us...> - 2003-01-08 11:26:08
|
Sven Luther <lu...@dp...> writes: > > > I'm about to implement rotation which is needed for devices like th= e ipaq.=20 > > > The question is do we flip the xres and yres values depending on th= e=20 > > > rotation or do we just alter the data that will be drawn to make th= e=20 > > > screen appear to rotate. How does hardware rotate view the x and y = axis? > > > Are they rotated or does just the data get rotated?=20 > >=20 > > Where are you going to implement the rotation? At the fbcon or fbdev = level? > >=20 > > Fbcon has the advantage that it'll work for all frame buffer devices. >=20 > 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. --=20 M=E5ns Rullg=E5rd mr...@us... |
|
From: John B. <jo...@gr...> - 2003-01-08 12:06:58
|
> > > > 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. |
|
From: Sven L. <lu...@dp...> - 2003-01-08 12:56:41
|
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 |
|
From: Antonino D. <ad...@po...> - 2003-01-08 17:07:53
|
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 |
|
From: James S. <jsi...@in...> - 2003-01-09 19:55:29
|
> 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. |
|
From: Antonino D. <ad...@po...> - 2003-01-10 10:37:33
|
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 |
|
From: James S. <jsi...@in...> - 2003-01-10 19:44:06
|
> > 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. |
|
From: Antonino D. <ad...@po...> - 2003-01-11 05:23:39
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X