We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3671 - GL attributes defaulting to OpenGL 2.1 can prevent window creation on platforms with multiple drivers
Summary: GL attributes defaulting to OpenGL 2.1 can prevent window creation on platfor...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 blocker
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.6
Depends on:
Blocks:
 
Reported: 2017-06-13 02:08 UTC by Simon Hug
Modified: 2017-09-04 02:07 UTC (History)
1 user (show)

See Also:

Attachments
Patch that adds an environment variable for the OpenGL version and profile mask defaults. (1007 bytes, patch)
2017-06-23 16:09 UTC, Simon Hug 		Details | Diff
Patch that adds a new function pointer to SDL_VideoDevice which the driver can use to override the defaults of the OpenGL attributes. (2.41 KB, patch)
2017-06-23 16:11 UTC, Simon Hug 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hug 2017-06-13 02:08:26 UTC 
The current defaults for the GL version and profile attributes set by SDL_GL_ResetAttributes[1] depend on what OpenGL and OpenGL ES versions are enabled at compile time. This can cause conflicts on window creation on platforms where multiple video drivers with differing OpenGL support are available.

For example, the Raspberry Pi can use the rpi and the x11 video driver. rpi only supports OpenGL ES 1 and 2 whereas x11 probably uses Mesa 3D's software renderer that (additionally to ES 1 and 2) supports OpenGL. When the SDL video subsystem is initialized with the rpi driver, the default GL version attributes get set to OpenGL 2.1. If the application doesn't change the attributes, EGL will be unable to create a surface and SDL_CreateWindow fails.

At first I thought a runtime check could determine what defaults it should use, but checking for available OpenGL versions can be really bothersome. Perhaps it's enough to just give the users an environment variable that can be changed so they don't have to change and recompile SDL or the application.

[1] https://hg.libsdl.org/SDL/file/819384789a7a/src/video/SDL_video.c#l2934
Comment 1 Alex Szpakowski 2017-06-13 16:12:31 UTC 
OpenGL ES 2 is not compatible with code written for desktop OpenGL 2.1, and vice versa. They're very close but not completely compatible (and OpenGL 2.1 has a huge amount of legacy functionality that ES 2 doesn't have).
Comment 2 Alex Szpakowski 2017-06-13 16:17:39 UTC 
To elaborate: If a user were to change the GL version requested by an app, the app would crash or fail to render properly because the different GL version does not have the same functionality (it's a different version for a reason).

There are also hardware-accelerated desktop OpenGL 2.1 drivers for the Raspberry Pi these days. I don't know if they work with EGL and videocore APIs or not though.
Comment 3 Simon Hug 2017-06-13 18:40:07 UTC 
I'm unsure if your comment is directed at me. In case mine was unclear: I'm not proposing that users can override what applications are setting, but what defaults SDL uses if the application does not set anything. This can be used as a workaround for the situation I described and encountered.

> There are also hardware-accelerated desktop OpenGL 2.1 drivers
> for the Raspberry Pi these days. I don't know if they work with
> EGL and videocore APIs or not though.

Oh, I completely forgot about VC4. I should have investigated what kind of behavior this driver shows with this issue. Going to have a look at it.
Comment 4 Simon Hug 2017-06-15 10:34:40 UTC 
Ok. The new VC4 driver disables the old firmwire-side driver, preventing the current version of the SDL rpi video driver from working. This issue doesn't apply to that configuration. Maybe that will change if a DRM/KMS driver gets someday added to SDL.
Comment 5 Simon Hug 2017-06-23 16:09:23 UTC 
Created attachment 2772 [details]
Patch that adds an environment variable for the OpenGL version and profile mask defaults.

Attaching a patch that could solve this issue by giving the user an environment variable that overrides the OpenGL version and profile mask when SDL_GL_ResetAttributes gets called.

While more options for users is always nice, this feels more like a workaround. I may have a better solution in the next comment.
Comment 6 Simon Hug 2017-06-23 16:11:57 UTC 
Created attachment 2773 [details]
Patch that adds a new function pointer to SDL_VideoDevice which the driver can use to override the defaults of the OpenGL attributes.

This patch adds the GL_ResetAttributes function pointer to the SDL_VideoDevice struct which gets called at the end of SDL_GL_ResetAttributes if the driver assigns a function to it. This allows the driver to override the defaults to its needs. In this case, the rpi driver knows that it can only provide OpenGL ES 1 and 2 and sets the version and profile mask accordingly. Drivers that don't care or are okay with the current defaults can set the pointer to NULL.
Comment 7 Alex Szpakowski 2017-07-14 02:29:31 UTC 
The second patch seems good to me.
Comment 8 Sam Lantinga 2017-08-11 17:36:03 UTC 
Ryan, can you review this?
Comment 9 Ryan C. Gordon 2017-09-03 06:06:45 UTC 
(In reply to Sam Lantinga from comment #8)
> Ryan, can you review this?

Being the genius I am, I totally wrote this exact same patch today when I was trying to test the RPi audio bug, thinking "why hasn't anyone noticed this before?" the whole time, even having read this bug report more than once.

That was https://hg.libsdl.org/SDL/rev/38f181f81476  ... so I guess we're fixed?  :)

--ryan.
Comment 10 Simon Hug 2017-09-03 20:21:26 UTC 
It looks fixed. Will test it later.

(In reply to Ryan C. Gordon from comment #9)
> "why hasn't anyone noticed this before?"

I'm guessing most people just disabled opengl like suggested in README-raspberrypi.md.

Did you try loading the GL library (through a renderer or whatever) in X with both drivers (x11 and rpi) compiled in? I'm more surprised you didn't tackle that. ;)
Comment 11 Simon Hug 2017-09-04 02:07:09 UTC 
Tested tip and it works.

> Did you try loading the GL library (through a renderer or whatever) in X...
Oops, I was thinking of EGL.