Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detecting and compiling OpenGL ES on raspberry pi #995

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Detecting and compiling OpenGL ES on raspberry pi #995

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.0
Reported for operating system, platform: Linux, ARM

Comments on the original bug report:

On 2013-08-01 13:07:01 +0000, Daniel Bünzli wrote:

Created attachment 1265
Raspberry pi config.log

Using the current tarball, the following had to be done to detect and compile the OpenGL ES support on a raspberry pi (using the recommended raspbian distribution).

  1. Invoke configure with

LDFLAGS="-L/opt/vc/lib"
CPPFLAGS="-I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads
-I/opt/vc/include/interface/vmcs_host/linux"
./configure

The reason is that OpenGL ES lives in

ls /opt/vc/include
bcm_host.h EGL GLES GLES2 IL interface KHR vcinclude VG WF

  1. Had to patch SDL_x11opengles.h as follows (egl.h is in /opt/vc/include/EGL)

diff -u src/video/x11/SDL_x11opengles.h.old src/video/x11/SDL_x11opengles.h
--- src/video/x11/SDL_x11opengles.h.old 2013-07-31 21:18:04.180819913 +0200
+++ src/video/x11/SDL_x11opengles.h 2013-07-31 21:08:17.463363606 +0200
@@ -25,7 +25,7 @@
#if SDL_VIDEO_OPENGL_ES || SDL_VIDEO_OPENGL_ES2
#include <GLES/gl.h>
-#include <GLES/egl.h>
+#include <EGL/egl.h>
#include <dlfcn.h>
#if defined(OpenBSD) && !defined(ELF)
#define dlsym(x,y) dlsym(x, "_" y)

I'm not an autoconf hacker so I don't really know how to test for the platform. Someone suggests checking for /opt/vc/include/bcm_host.h here [1]. In any case I attached the config.log.

Besides I couldn't make any test since I have no actual display to plug into the pi for now… I may get by to you once that and time happens.

I think however that there may be additional things that should be done in SDL_{Init,Quit} on this platform, namely calling bcm_host_{init,bcm_host_deinit}(). I couldn't find proper documentation for these functions but most sample code floating around on the internet does it, it seems necessary to be able to access the gpu. There is some documentation about the graphics architecture here [2] and the actual contents of the /opt/vc hierarchy (including the headers) can be found here [3].

[1] http://raspberrypi.stackexchange.com/questions/754/how-can-i-detect-that-im-compiling-for-raspberry-pi
[2] http://elinux.org/RPi_VideoCore_APIs
[3] https://github.com/raspberrypi/firmware/tree/master/opt/vc

On 2013-08-01 17:54:04 +0000, Gabriel Jacobo wrote:

If you want to run SDL under X11, I'm willing to bet that it should work out of the box or nearly as much, after all it's Linux+X11+OpenGLES 2 (that is, there would be no need to mess around with BCM internals).
Regarding the include paths, it's quite strange that the GNU tools don't have this path (/opt/vc/include) hardcoded in.

The really interesting thing would be to use the DirectFB backend SDL together with OpenGL ES 2 and ditch X11. I've always had interest in that, and there was talk of a GSOC project for this, but it hasn't gone anywhere...yet.

On 2013-08-01 18:32:37 +0000, Daniel Bünzli wrote:

(In reply to comment # 1)

If you want to run SDL under X11, I'm willing to bet that it should work out
of the box or nearly as much, after all it's Linux+X11+OpenGLES 2 (that is,
there would be no need to mess around with BCM internals).

I can't really comment on that. But maybe you are right and its the result of people copy/pasting from that sample code [1] (which doesn't use X11).

https://github.com/raspberrypi/firmware/blob/master/opt/vc/src/hello_pi/hello_triangle/triangle.c

Regarding the include paths, it's quite strange that the GNU tools don't
have this path (/opt/vc/include) hardcoded in.

Any idea if that should be reported somewhere else ?

The really interesting thing would be to use the DirectFB backend SDL
together with OpenGL ES 2 and ditch X11. I've always had interest in that,
and there was talk of a GSOC project for this, but it hasn't gone
anywhere...yet.

Yes that would be neat. In any case there's this http://directfb.org/raspbian/README

On 2013-08-06 20:26:48 +0000, Gabriel Jacobo wrote:

Assigning this to me, I've finally understood what Daniel meant initially and want to take a crack at implementing a Raspberry EGL based video backend (with no DirectFB). Wish me luck!

On 2013-08-07 04:19:36 +0000, Sam Lantinga wrote:

Good luck! :)

On 2013-08-07 22:13:14 +0000, Gabriel Jacobo wrote:

Created attachment 1275
Raspberry Pi support v1

This patch adds support for a video backend for the Raspberry Pi, it should work with just configure;make;sudo make install

I tested it with testrendercopyex, I'm getting about 60FPS with the OpenGL ES2 renderer (and some funny glGetError 0x505 strings on the console).

Feedback is appreciated!

On 2013-08-12 13:06:45 +0000, Joe LeVeque wrote:

Created attachment 1282
Raspberry Pi support v1.1

Attached new patch file, as original one was failing to patch config.guess.

On 2013-08-29 16:20:22 +0000, Gabriel Jacobo wrote:

Created attachment 1314
Raspberry Pi support v2

The attached patch has:

  • EGL support based on the EGL common code
  • udev support
  • evdev support

Once this lands, there's an opportunity to reduce the linux joystick code a great deal as all of the udev functionality can be removed from there. The udev code also emits events for sound devices, so there's another area that can be improved.

On 2013-08-29 19:39:56 +0000, Aloshi wrote:

Hello, great to see some work on this! :)

I'm the dev for EmulationStation, the front-end used by the RetroPie emulator package on the Pi, and I'm currently working on moving it from SDL 1.2 to SDL 2. Since resources are tight on the Pi, ES is designed for use in the terminal. With SDL 1.2, I managed that by setting up a "dummy" 1x1 window with fbcon for input and handling all the OpenGL ES1/EGL stuff myself. With SDL 2, the fbcon driver was dropped, so the only other option for terminal use is directfb...which I can't get to work for some reason...which makes your new driver the best solution at the moment! :)

I haven't tested it yet, but I can give one tip: bcm_host_init()/bcm_host_deinit() breaks if used multiple times throughout the program. Which means if you call SDL_Quit() then SDL_Init() a few times (I think something like 3-6 times), it'll eventually stop working. This almost never matters in practice, but EmulationStation is one of the few applications that actually depends on being able to deinit/reinit the video subsystem multiple times. Hopefully SDL has a mechanism for one-time init/deinit somewhere.

On 2013-08-29 20:01:25 +0000, Gabriel Jacobo wrote:

(In reply to Aloshi from comment # 8)

I haven't tested it yet, but I can give one tip:
bcm_host_init()/bcm_host_deinit() breaks if used multiple times throughout
the program. Which means if you call SDL_Quit() then SDL_Init() a few times
(I think something like 3-6 times), it'll eventually stop working. This
almost never matters in practice, but EmulationStation is one of the few
applications that actually depends on being able to deinit/reinit the video
subsystem multiple times. Hopefully SDL has a mechanism for one-time
init/deinit somewhere.

Can you elaborate on why you reinit the video subsystem?

On 2013-08-29 21:01:21 +0000, Aloshi wrote:

(In reply to Gabriel Jacobo from comment # 9)

Can you elaborate on why you reinit the video subsystem?

When EmulationStation launches a game, it hands off control to the emulator. With the new SDL 2 code I could probably get away with just destroying the window. Since I don't really know the details of what SDL actually does during SDL_Quit I can't really make any claims about how necessary it is - I originally just wanted to be as sure as possible that it wouldn't affect the emulator.

On 2013-09-18 22:39:48 +0000, npepinpe wrote:

(In reply to Gabriel Jacobo from comment # 7)

Created attachment 1314 [details]
Raspberry Pi support v2

The attached patch has:

  • EGL support based on the EGL common code
  • udev support
  • evdev support

Once this lands, there's an opportunity to reduce the linux joystick code a
great deal as all of the udev functionality can be removed from there. The
udev code also emits events for sound devices, so there's another area that
can be improved.

Hi Gabriel,

Thanks for your work on this, it's much appreciated! I can't seem to apply the patch, however. Is there anything special I should know about the process?

Thanks :)

On 2013-09-19 12:46:07 +0000, Gabriel Jacobo wrote:

Created attachment 1332
Raspberry Pi support v3

The attached patch adds UDEV/EVDEV input support for mouse and keyboard, mouse input and mouse pointer are buggy right now.

On 2013-09-26 13:57:33 +0000, Gabriel Jacobo wrote:

Created attachment 1338
Raspberry Pi support v4 (RC)

Attaching "Release Candidate" patch, everything should be working!

For those interested in providing feedback, but not interested enough to wait 30 minutes for SDL to compile on the Raspberry, I've uploaded pre compiled binaries here: https://www.dropbox.com/s/9fndtw6zs16ptgg/SDL2-raspberrypi.tar.gz

On 2013-09-27 14:59:07 +0000, Gabriel Jacobo wrote:

Created attachment 1340
Raspberry Pi support v5 (RC)

On 2013-09-28 01:49:19 +0000, Aloshi wrote:

My observations using the "Raspberry Pi support v4" pre-compiled binary you provided with EmulationStation:

  1. SDL_GetDisplayMode(0, 0, &somestruct) (before creating any window) seems to return garbage for "w" and "h". SDL_GetDesktopDisplayMode(0, &somestruct) works fine though (I should probably be using that anyway).

  2. Keyboard input seems to leak through into the terminal. Not sure if there's anything you can do about that.

  3. Key repeats don't set the proper "repeat" value on their event struct. Looking at src/events/SDL_keyboard.c, line 756, it looks like the fix is just to omit your "key release" event for repeats?

  4. No SDL_TEXTINPUT yet, it looks like? (Ironically, this is what initially prompted me to switch from SDL 1.2 to SDL 2.)

  5. Tested a joystick (wired 360 controller), everything seemed to work fine.

  6. No problems with re-initialization from what I can tell, yay! :)

Excellent work!

On 2013-09-28 16:38:57 +0000, Gabriel Jacobo wrote:

Commited: http://hg.libsdl.org/SDL/rev/e4c38f17bfad

(In reply to Aloshi from comment # 15)

My observations using the "Raspberry Pi support v4" pre-compiled binary you
provided with EmulationStation:

  1. SDL_GetDisplayMode(0, 0, &somestruct) (before creating any window) seems
    to return garbage for "w" and "h". SDL_GetDesktopDisplayMode(0, &somestruct)
    works fine though (I should probably be using that anyway).

This should be fixed.

  1. Keyboard input seems to leak through into the terminal. Not sure if
    there's anything you can do about that.

I can try redirecting stdin to /dev/null, I wonder if that will fix that.

  1. Key repeats don't set the proper "repeat" value on their event struct.
    Looking at src/events/SDL_keyboard.c, line 756, it looks like the fix is
    just to omit your "key release" event for repeats?

This should be fixed.

  1. No SDL_TEXTINPUT yet, it looks like? (Ironically, this is what initially
    prompted me to switch from SDL 1.2 to SDL 2.)

Yeah, this one may take some time. We can not use XKB to map keycodes to text input (it would bring along X11 dependencies), so I'm going to dig into how the kernel does its Unicode translation and see if any of that can be used in SDL.

On 2013-09-28 17:54:38 +0000, Gabriel Jacobo wrote:

Marking as fixed, will open a separate bug for SDL_TEXTINPUT

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant