| Summary: | GL attributes defaulting to OpenGL 2.1 can prevent window creation on platforms with multiple drivers | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Simon Hug <chli.hug> |
| Component: | video | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | blocker | ||
| Priority: | P2 | CC: | amaranth72 |
| Version: | HG 2.0 | Keywords: | target-2.0.6 |
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
Patch that adds an environment variable for the OpenGL version and profile mask defaults.
Patch that adds a new function pointer to SDL_VideoDevice which the driver can use to override the defaults of the OpenGL attributes. |
||
|
Description
Simon Hug
2017-06-13 02:08:26 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). 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. 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.
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. 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.
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.
The second patch seems good to me. Ryan, can you review this? (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. 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. ;) 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.
|