This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: iOS 6, iPhone/iPod touch

Comments on the original bug report:

On 2013-06-02 15:53:38 +0000, Wouter van Oortmerssen wrote:

using SDL_GetNumDisplayModes and SDL_GetDisplayMode I iterate to find the largest landscape mode, request it using SDL_CreateWindow, the check afterwards with SDL_GetWindowSize to find that it has selected the equivalent portrait mode anyway. I have the portrait modes even disabled in the Xcode project, but that makes no difference.

I can't verify if it actually opens in landscape or not, since Bug 1819 is stopping me from launching at all.

On 2013-06-04 19:19:02 +0000, Wouter van Oortmerssen wrote:

and this one is caused by not calling SDL_SetHint("SDL_HINT_ORIENTATIONS", "LandscapeLeft LandscapeRight"); Not sure why SDL can't deduce I want landscape from the resolution passed to SDL_CreateWindow

On 2013-06-05 02:56:44 +0000, Sam Lantinga wrote:

It's supposed to. Can you attach a test case?

FYI, this works fine for Maelstrom on my setup.

On 2013-06-05 13:52:09 +0000, Wouter van Oortmerssen wrote:

Sure. This is running on an iPad 3rd gen IOS 6.

Replace the contents of main() in sdltest.c with:

---

if (SDL_Init(SDL_INIT_VIDEO/* | SDL_INIT_AUDIO*/) < 0)
{
    SDLError("Unable to initialize SDL");
}
    
SDL_LogSetAllPriority(SDL_LOG_PRIORITY_WARN);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);    
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);

int landscape = 1;
int modes = SDL_GetNumDisplayModes(0);
int sx = 0, sy = 0;
for (int i = 0; i < modes; i++)
{
    SDL_DisplayMode mode;
    SDL_GetDisplayMode(0, i, &mode);
    if (landscape ? mode.w > sx : mode.h > sy)
    {
        sx = mode.w;
        sy = mode.h;
    }
}

printf("picked: %d %d\n", sx, sy);

SDL_Window *_sdl_window = NULL;
SDL_GLContext _sdl_context = NULL;

_sdl_window = SDL_CreateWindow("fred",
                               0, 0,
                               sx, sy,
                               SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN | SDL_WINDOW_BORDERLESS);

//SDL_SetHint("SDL_HINT_ORIENTATIONS", "LandscapeLeft LandscapeRight");

int ax = 0, ay = 0;
SDL_GetWindowSize(_sdl_window, &ax, &ay);

printf("given: %d %d\n", ax, ay);

---

Now make sure the iPad is physically standing in landscape mode on your desk.
running it gives:

picked: 2048 1536
given: 1536 2048

Now uncomment the hint line:

picked: 2048 1536
given: 2048 1536

Now put the iPad in portrait on your desk before running (hint still uncommented):

picked: 2048 1536
given: 1536 2048

Now change in the project settings for supported interface orientations to only support landscape, and all the above test cases give landscape mode correctly. So I guess that is the current solution, though in my case it be great to be able to let SDL pick landscape correctly or not.

On 2013-06-06 02:16:01 +0000, Sam Lantinga wrote:

I can reproduce this. I'll look into it tomorrow.

Thanks!

On 2013-06-06 02:49:37 +0000, Sam Lantinga wrote:

Okay, I dug into this a little more. The hint where you have it in the example does nothing. It's never checked.

This is a change in iOS 6.0, SDL tries to change the orientation of the main screen but the OS doesn't allow it because there isn't a view created at that point.

If you set your desired orientation in your application's property summary, it'll work fine.

It also works the way you expect on iOS 5.1.

I'll have to think about the best way to solve this. It may be that we lie to the application until we have a view created and can actually change the orientation.

In any case, if your application only supports landscape mode then you'll want to set that property in the info.plist and you should be fine.

On 2013-07-12 22:15:57 +0000, Ryan C. Gordon wrote:

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 2.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

On 2015-04-10 02:46:11 +0000, Ryan C. Gordon wrote:

This bug should be fixed by the changes made for Bug # 2798. Please reopen if that's not the case.

Thanks!

--ryan.