| Summary: | SDL_SetVideoMode with SDL_OPENGL crashes when using two monitors | ||
|---|---|---|---|
| Product: | SDL | Reporter: | HyperHacker <hyperhacker> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P1 | CC: | tofu |
| Version: | 1.2.10 | ||
| Hardware: | x86 | ||
| OS: | Windows (XP) | ||
| Attachments: | Simple test case | ||
|
Description
HyperHacker
2006-06-21 20:10:51 UTC
Created attachment 140 [details]
Simple test case
This should create a 640x480 OpenGL window then close. When the bug occurrs, it creates the window then shows Windows' Application Error dialog.
This is interesting. Here's the results from SDL_GetVideoInfo: HW Surface: 0 Window Manager: 1 Hardware blit: 0 With colour key: 0 With alpha: 0 Software blit: 0 With colour key: 0 With alpha: 0 Colour fill: 0 VRAM: 0 KB Colour depth: 32 bits per pixel This happens whether I have one monitor or both enabled, but despite this, SDL_SetVideoMode still succeeds when only one monitor is enabled. I did some more poking, and this only seems to happen if the AGP card is set as primary in Windows. The PCI card is set as primary in the BIOS as it won't work otherwise. I swapped the monitors and made the PCI card primary in Windows, and it works. However it still crashes with the AGP card set to primary, so this is more of a workaround than a fix. Also, I tried the test case using main() instead of WinMain(), and besides not printing anything to the console (I suspect a mistake on my part somewhere), it didn't make a difference. Any reason you can't get a stack dump? If you can't get a stack dump, can you add some debug print statements in the SDL video initialization code to see how far it gets? (In reply to comment #4) > Any reason you can't get a stack dump? > If you can't get a stack dump, can you add some debug print statements in the > SDL video initialization code to see how far it gets? > I might just be doing it wrong, but when I try to get a stack dump, it does so after the exception handler has executed, so the information is no good (it tells me what's happening in the "fatal error occurred" dialog, not what happened when the error occurred). As for testing, I removed the second video card from my computer. If you absolutely can't find anyone else to test, I can put it back in for this purpose, but it'd be difficult. (I'm running both monitors from the AGP card now - it has a DVI port - and SDL is working fine with that setup.) I think this might be related. If there are any translucent windows on the screen while an SDL+OpenGL program is running, they flicker quite a bit. If such a window is visible while the SDL_SetVideoMode() call is executing, the call may hang. How often it hangs seems random but can be up to 90% of the time in some cases. Someone I was speaking with on IRC might have tracked this down separate from this bug report. (I've changed her name to "person" here, since I'm reposting the chatlog without permission). It sounds like the same issue. I'm not prepared to work on this bug, but the info might make it easy for someone else to do so. <person> Today's pleasant discovery: SDL's win32 opengl support *just won't work* if you have three video cards in the machine. <person> Do not ask how I know this. Suffice it to say that I have an artist who really, really likes his multimonitor setup. <person> more specifically, it looks like the problem is (at least, according to gDebugger) when the win32 driver loads wglChoosePixelFormatARB() or wglGetPixelFormatAttribivARB(), it loads the extensions relative to gl context #0 <person> that GL context may not exist by the time those functions are actually called <person> so, AFAICT, when he loads SDL with his four monitor setup, the context created the second time apparently just ... blows up. I don't know if this is because it's on another monitor, or on another video card, or what. Probably the other video card, as SDL works fine on my multimonitor system <person> he has a GeForce FX 5200, a GeForce 4 MX, and a VIA/S3 Unichrome on-board. <person> the bad stuff happens in WIN_GL_SetupWindow() - look for: <person> if (this->gl_data->WGL_ARB_pixel_format) <icculus> ok, to be clear, you're calling SDL_SetVideoMode() a second time, or calling SDL_Quit() and then reinitting? <person> neither. <person> Call SDL_Init(SDL_INIT_VIDEO) and do the usual SDL_SetGraphicsMode() song and dance <icculus> and it blows up on the first call? <person> at some point this calls Init_WGL_ARB_Extensions() <person> which creates a new GL context, loads driver pointers, *then deletes that context in the same procedure* <icculus> oh <person> the blowup is after you set the video mode, for the first time. <person> it doesn't even get off the ground here. --ryan. Bumping a bunch of bugs to Priority 1 for consideration for the 1.2.12 release. --ryan. I'll look at this. I may be able to throw two video cards into a system and debug it. I'm not sure how to choose a pixel format to create a context if I have to create a context to get the function pointers to choose the pixel format. :) Does anyone have an example that works correctly in this configuration? I tested this extensivey with a Radeon 9200 and Matrox Millennium II, on Windows XP SP2 and had no problems. I tried both cards as primary in a variety of bit depths and resolutions, and when the testgl application was started on the Matrox it would run using the GDI driver, and when started on the Radeon it would run using the accelerated ATI driver. Are you testing with the latest drivers? Does the bug still occur with the SDL subversion snapshot? http://www.libsdl.org/tmp/SDL-1.2.12.zip Let me know if you need a precompiled DLL. Are you able to debug the problem at all? If not, and you're willing to send the problematic video card combination to me, I'll see if I can reproduce the configuration and then send them back. Okay, I think I figured out how to fix this. I changed the SDL code so that it doesn't use the wglChoosePixelFormatARB() function after the temporary context has been deleted. Can you try this and let me know if it works? http://www.libsdl.org/tmp/SDL.dll My IRC contact confirmed this is working now. --ryan. (In reply to comment #6) > I think this might be related. If there are any translucent windows on the > screen while an SDL+OpenGL program is running, they flicker quite a bit. If > such a window is visible while the SDL_SetVideoMode() call is executing, the > call may hang. How often it hangs seems random but can be up to 90% of the time > in some cases. > For the record, these problems were caused by crappy video drivers. A new video card fixed them both. |