opengl/ changing screen resolution


27 posts   Page 1 of 2   1, 2
by joco » Sat Jun 02, 2012 2:05 pm
Hi experts,

Could someone please show some piece of code to change the resolution when app inits opengl? I do understand that this can be done with fbset, which is a linux command basicly. What I'd like to do is
set the resolution for my opengl app by the app itself - e.g. practically run a game with a low resolution screen like 640x480, and restore the original screen resolution when the app quits.
The demo called hello_triangle shows the initial steps, but I can not find a way to change the physical screen resolution. I do not want to use opengl to scale my scene, I'd like to use the real resolution that I choose.

thanks

Joseph
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by dattrax » Sat Jun 02, 2012 11:28 pm
I've not got a TV connected to my Pi at the moment, but have you tried something like this?

Code: Select all
   dst_rect.x = 0;
   dst_rect.y = 0;
   dst_rect.width = state->screen_width;
   dst_rect.height = state->screen_height;
     
   src_rect.x = 0;
   src_rect.y = 0;
   src_rect.width = 640 << 16;
   src_rect.height = 480 << 16;       

   dispman_display = vc_dispmanx_display_open( 0 /* LCD */);
   dispman_update = vc_dispmanx_update_start( 0 );
         
   dispman_element = vc_dispmanx_element_add ( dispman_update, dispman_display,
      0/*layer*/, &dst_rect, 0/*src*/,
      &src_rect, DISPMANX_PROTECTION_NONE, 0 /*alpha*/, 0/*clamp*/, 0/*transform*/);
     
   nativewindow.element = dispman_element;
   nativewindow.width = 640;
   nativewindow.height = 480;
   vc_dispmanx_update_submit_sync( dispman_update );


The GL is displayed on a HW overlay (if I remember correctly), so it wont change the underlying resolution, but will render @ 640x480 and then upscale.
Posts: 50
Joined: Sat Dec 24, 2011 5:09 pm
by shirro » Sun Jun 03, 2012 3:13 am
This is how I do it, upscale with dispmanx. I had to do this to get the frame rates up on a few things.
Posts: 248
Joined: Tue Jan 24, 2012 4:54 am
by joco » Sun Jun 03, 2012 6:43 pm
Thanks guys, I will try it. BTW this isn't a solution, only a workaround. :-)
Do you know if an OS level vc** command can change the resolution?

I tried fbset, and the screen itself seems to be changed, but my monitor still report HD
resolution even if I do fbset "640x480-60". So dispman is cheating somehow I guess.

If only there was a good documentation of all the video features....

Thx
J
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by dattrax » Sun Jun 03, 2012 11:50 pm
Hi,

I would guess that the 'console' is on another HW graphics plane. When you do an 'fbset' its probably doing the same thing as can be controlled with the GLES graphics plane.

I wouldn't go so far to call it a 'workaround', as this implies its broken. I would be more diplomatic and say it works differently than I expected.

Jim
Posts: 50
Joined: Sat Dec 24, 2011 5:09 pm
by dom » Sun Jun 03, 2012 11:59 pm
joco wrote:Thanks guys, I will try it. BTW this isn't a solution, only a workaround. :-)
Do you know if an OS level vc** command can change the resolution?


What do you mean by the resolution? The actual physical mode the display is in? That's almost certainly not what you want to do.

Suppose I want to run your program on my NTSC composite display? That's not going to run at whatever resolution you have set.
There's no guarantee the HDMI modes supported by my TV will work on your TV.

The dispmanx solution is the correct one.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by joco » Mon Jun 04, 2012 6:36 am
What do you mean by the resolution? The actual physical mode the display is in? That's almost certainly not what you want to do.


Actually, this is exactly what I wanna do. Whether it's work with your display, a different question. Don't get me wrong, I understand the portability issues and appreciate all the suggestions indeed. But I asked a technical question and I don't get the answer. This is perhaps, because there is no proper documentation for the pi, as it's still quite new. Also understand that everything is still under development.

But looking arount the world, changing the resolution of the screen is such a common task to me in 2012. Not only on PI, but on other platforms as well. Why should I waste the memory and GPU resources for a HD resolution (e.g. 1920x1080), when I only need 640x480 for a small 2d game?
Ok dispman can scale my scene also openGL can. Clear. Even if it's cheap, it costs some CPU/GPU power I am sure.

Again, thanks for your suggestions. Keep searching for the answer :)
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by dattrax » Mon Jun 04, 2012 9:43 am
Why should I waste the memory and GPU resources for a HD resolution


I dont believe you are, because the your assumption is the physical display has a backing store. I don't believe it does. See drawing
Attachments
guess.png
guess.png (20.88 KiB) Viewed 7221 times
Posts: 50
Joined: Sat Dec 24, 2011 5:09 pm
by shirro » Mon Jun 04, 2012 10:02 am
I get the impression the video scaling is in hardware and is effectively free. It is a lot easier to scale to whatever resolution the screen is in than it would be to go through a lot of negotiation to find available modes and change them. People have probably fiddled with overscan etc to get things just right in a particular mode and if you were to go and change it vs do a free hardware scale you might not end up with a good result.
Posts: 248
Joined: Tue Jan 24, 2012 4:54 am
by dom » Mon Jun 04, 2012 10:09 am
joco wrote:Why should I waste the memory and GPU resources for a HD resolution (e.g. 1920x1080), when I only need 640x480 for a small 2d game?


There will be a framebuffer for the console, or the EGL surface but it will only be the size of the source rectange passed to dispmanx.
The scaling to the destination rectange (and so display resolution) size is done in hardware.

So there is no memory or memory bandwidth cost when the display is physically larger than you require - all that matters is the source rectangle size.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Narishma » Mon Jun 04, 2012 3:42 pm
dom wrote:
joco wrote:Why should I waste the memory and GPU resources for a HD resolution (e.g. 1920x1080), when I only need 640x480 for a small 2d game?


There will be a framebuffer for the console, or the EGL surface but it will only be the size of the source rectange passed to dispmanx.
The scaling to the destination rectange (and so display resolution) size is done in hardware.

So there is no memory or memory bandwidth cost when the display is physically larger than you require - all that matters is the source rectangle size.

Is it also free if the source surface is larger than the display resolution? Say, if you render at 720p or 1080p and want to display at an NTSC resolution. Does the hardware downscale it for free?
Posts: 151
Joined: Wed Nov 23, 2011 1:29 pm
by dom » Mon Jun 04, 2012 4:04 pm
Narishma wrote:Is it also free if the source surface is larger than the display resolution? Say, if you render at 720p or 1080p and want to display at an NTSC resolution. Does the hardware downscale it for free?


Yes.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by joco » Tue Jun 05, 2012 8:20 am
Hi,

Ok, I am convinced. I will do the hardware stretch then. BTW I think my graphics_get_display_size() function is wrong. Whatever display I connect, it always report HD resolution. How can I fix that bug?

Jozsef
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by dom » Tue Jun 05, 2012 8:44 am
joco wrote:Hi,

Ok, I am convinced. I will do the hardware stretch then. BTW I think my graphics_get_display_size() function is wrong. Whatever display I connect, it always report HD resolution. How can I fix that bug?

Jozsef


Update firmware (e.g. with Hexxeh's updater tool)
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by joco » Wed Jun 06, 2012 11:29 am
Thank you guys. After the firmware update graphics_get_display_size() reports back the real resolution and stretching by dispman is working fine.

Thanks again.
J
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by joco » Sat Jun 09, 2012 5:24 am
Hi

So I could make it work with triangle.c, now it renders 640x480 and then dispmanx stretches the native window. Another question: is there a way to access the native window's surface directly?

Code: Select all
   dst_rect.x = 0;
   dst_rect.y = 0;
   dst_rect.width = state->screen_width;
   dst_rect.height = state->screen_height;

   src_rect.x = 0;
   src_rect.y = 0;
   src_rect.width = 640 << 16;
   src_rect.height = 480 << 16;

   dispman_display = vc_dispmanx_display_open( 0 /* LCD */);
   dispman_update = vc_dispmanx_update_start( 0 );

   dispman_element = vc_dispmanx_element_add ( dispman_update, dispman_display,
      0/*layer*/, &dst_rect, 0/*src*/,
      &src_rect, DISPMANX_PROTECTION_NONE, 0 /*alpha*/, 0/*clamp*/, 0/*transform*/);

   nativewindow.element = dispman_element;
   nativewindow.width = 640;
   nativewindow.height = 480;
   vc_dispmanx_update_submit_sync( dispman_update );

   state->surface = eglCreateWindowSurface( state->display, config, &nativewindow, NULL );
   assert(state->surface != EGL_NO_SURFACE);

   // connect the context to the surface
   result = eglMakeCurrent(state->display, state->surface, state->surface, state->context);
   assert(EGL_FALSE != result);


This is the initalization part, and after this I'd like to access my surface directly, WITHOUT openGL. Is there an easy way? (assuming that native window's surface is 32bits RGBA or ARGB, there should be a pointer to that memory array)

Joseph
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by joco » Wed Jun 13, 2012 1:04 pm
Does anyone know the answer? Is there a way to access the native window's surface directly? Without openGL.
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by dom » Wed Jun 13, 2012 1:10 pm
joco wrote:Does anyone know the answer? Is there a way to access the native window's surface directly? Without openGL.


Are you talking about the (console) framebuffer? Or the EGL framebuffer?
(the latter will be a no).
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by joco » Thu Jun 14, 2012 7:02 am
Hi dom,

There is another topic about this accessing the display surface in YUV format.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33&t=7672

I wonder if there is a way to do the same thing with the RGBA or RGB color space?

Thanks
J
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by dom » Thu Jun 14, 2012 8:47 am
Yes, dispmanx overlays can be RGB565, RGB888, RGBA32 or YUV420.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by adammw » Fri Jun 15, 2012 4:45 am
I was looking around in vc_tvservice.h and I wondering any of those APIs may help to achieve the original goal of dynamically changing resolution rather than scaling. There's a bunch of vc_hdmi_power_on functions that take arguments and try to find the closest supported resolution or framerate to what you want, or the monitor's prefered one, etc. However, I just tried them out with some simple C code calling them and it doesn't appear to do anything to the console output, and if you try to turn the output off with vc_tv_power_off I can't seem to get it to turn back on.
Posts: 21
Joined: Fri Jun 15, 2012 4:28 am
by joco » Sun Jun 17, 2012 6:42 am
Hi adammw

Frankly it is kinda annoying that these features are not documented at all. We do have an excellent video display hardware which can do anyting that you'd ever need. Work with PAL or NTSC displays, HDMI modern ones etc. Then you can not do the absolute simplest tasks like changing bit depth or resolution. To me linux and X is not that interesting. We have seen linux and X running on better or faster harware. I am interested in bear low level functions of PI and can't get info for them.

Joseph
Posts: 15
Joined: Sat Jun 02, 2012 1:54 pm
by AndyEsser » Wed Jun 20, 2012 6:49 am
The reason why the vc_* functions are not better documented, I believe, is because most of those functions are proprietary Broadcom calls, with no released source or documentation - until that changes I don't see decent documentation being put together.
User avatar
Posts: 9
Joined: Tue Jun 19, 2012 7:01 pm
Location: Warwick, United Kingdom
by adammw » Wed Jun 20, 2012 7:42 am
Its pretty damn pointless to give us header files and sample applications then go back and say sorry we can't tell you how they work but your still allowed to use them. Makes all that GPU power feel very wasteful, and hard for anyone to tinker with- let alone for kids.
What about we start a wiki (page) to try and write community documentation for all the closed broadcom stuff?

Anyway that issue aside, I managed to get some of these apis working - see the source code of https://github.com/adammw/rpi-output-swapper
Posts: 21
Joined: Fri Jun 15, 2012 4:28 am
by ComputerJock » Tue Aug 21, 2012 2:30 am
I'll ask here, if not correct is there a better place to ask?

What are the memory layout requirements for the image for each of the various VC_FORMAT_* defines for VC_IMAGE_FORMAT_T in vc_dispservice_x_defs.h. Specifically I'd like to know how to change hello_dispmanx to do RGBA32. And then how does the alpha stuff work?

Thanks.
Posts: 14
Joined: Tue Aug 07, 2012 11:21 pm