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 5128 - rpi video backend doesn't work with OpenGL on Raspberry Pi 4
Summary: rpi video backend doesn't work with OpenGL on Raspberry Pi 4
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: ARM Linux
: P2 normal
Assignee: Manuel Alfayate Corchete
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-08 23:51 UTC by Ryan C. Gordon
Modified: 2020-10-10 14:13 UTC (History)
1 user (show)

See Also:

Attachments
Initial fix for Raspberry Pi 4 (1.80 KB, patch)
2020-05-09 06:57 UTC, Ryan C. Gordon 		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 Ryan C. Gordon 2020-05-08 23:51:40 UTC 
SDL works fine on a virtual terminal on a Raspberry Pi 3 and earlier, using SDL's "rpi" video backend, but it doesn't work on Raspberry Pi 4.

Running testsprite2 in this configuration produces:

    INFO: Couldn't create window: Could not initialize EGL

My basic understanding from reading RetroPie developer discussions is that the dispmanx API doesn't work on the RPi4, and you have to use kmsdrm instead.

SDL has a kmsdrm backend, too, but it currently produces this for testsprite2:

    INFO: Couldn't create window: Could not initialize OpenGL / GLES library

To be clear: SDL+X11 still works fine on the RPi4--accelerated GLX and all--but this affects things that want to use a Pi as a game console or kiosk thing without X11.

--ryan.
Comment 1 Ryan C. Gordon 2020-05-09 06:57:47 UTC 
Created attachment 4335 [details]
Initial fix for Raspberry Pi 4


This patch gets it running again, but it's not ready for revision control.

The basic idea is the KMSDRM target works, but it tries to default to desktop OpenGL, which causes SDL_GLES_LoadLibrary to fail, etc.

Setting the default to GLES2 lets it slide through far enough that desktop GL _will_ work, fwiw, but generally most things want GLES2 on the Raspberry Pi in any case, so this default makes sense regardless.

But this patch needs a better way to decide that it's running on a Raspberry Pi than "the rpi video driver is also built into this copy of SDL." This is trivial, I assume, but I don't know a good preprocessor check at the moment.

Further work after that: the 2D render API needs to default to GLES2 on this platform; GLES1 and desktop OpenGL will all work but they are slower, and right now SDL picks desktop OpenGL.

--ryan.
Comment 2 Cameron Gutman 2020-05-11 16:16:26 UTC 
I found that --enable-video-kmsdrm --disable-video-rpi results in working video on the Raspberry Pi 4 using KMSDRM, so that's what I've been using.

It was several months ago that I debugged this, but if I remember correctly, SDL_egl.c picks different GL libraries if SDL_VIDEO_DRIVER_RPI is specified at build.
Comment 3 Sam Lantinga 2020-10-09 23:59:18 UTC 
Manuel, is this something that you can look at?
Comment 4 Manuel Alfayate Corchete 2020-10-10 14:13:54 UTC 
@Sam Lantiga: Yes, but I believe dispmanx is more or less deprecated now, so maybe removing the specific Raspberry Pi support would be the easiest way to avoid this problem. All Pis should be using KMSDRM by now, not dispmanx anymore.
What do you think?