Weird,
I disable the stereo api in the display settings.
I set up a pixel format desriptor ‘want’ with PFD_STEREO,
then choosepixelformat(want), then describepixelformat(got), the ‘got’ advertises that I got PFD_STEREO.
If I then continue to setpixelformat, create a gl context, and start rendering into backleft/backright buffers the application hangs (not sure where, but that’s nothing to do with my question - suffice to say it just don’t work right).
Mmm, so I suppose the driver advertises stereo pixel formats even when the api is disabled. Ok, that’s ok.
If I then, after creating my context (on a dc with a stereo pixel format, because how do I know it’s disabled at this point?), and then do this:-
wglMakeCurrent(dc, g_hGLRC);
GLboolean stereo_enabled;
glGetBooleanv(GL_STEREO, &stereo_enabled);
stereo_enabled is GL_TRUE!
So, how do I know when the stupid user has not enabled the stereo API? Is there no mechanism?
Aye Nutty, you must be right. The pixel format lark could be blamed on microsoft, as it probably hasn’t provided a mechanism for driver writers to dynamically alter pf lists depending on device settings, but when it comes to the opengl ICD lying about stereo being enabled, well that mistake must be nvidias.
I’ve worked with display drivers enough to have discovered that certain things like PFD_ flags may be compiled into the driver binary without regard to the actual run-time environment settings. This has been the case with PFD_STEREO pixel format specs not accurately reflecting the display driver’s current configuration, only that the graphics board is stereo capable at all or not. Unfortunately lack of interest in stereo support in general leaves items like this at the bottom of a driver writer’s to-do list, so you’ll have to come up with your own empirical work-around.