You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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].
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).
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.
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!
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:
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).
Keyboard input seems to leak through into the terminal. Not sure if there's anything you can do about that.
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?
No SDL_TEXTINPUT yet, it looks like? (Ironically, this is what initially prompted me to switch from SDL 1.2 to SDL 2.)
Tested a joystick (wired 360 controller), everything seemed to work fine.
No problems with re-initialization from what I can tell, yay! :)
Excellent work!
On 2013-09-28 16:38:57 +0000, Gabriel Jacobo wrote:
My observations using the "Raspberry Pi support v4" pre-compiled binary you
provided with EmulationStation:
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.
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.
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.
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
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Raspberry pi config.log (config.log, application/octet-stream, 2013-08-01 13:07:01 +0000, 268854 bytes)Raspberry Pi support v1 (bug2005.patch, text/plain, 2013-08-07 22:13:14 +0000, 39022 bytes)Raspberry Pi support v1.1 (file_2005.txt, text/plain, 2013-08-12 13:06:45 +0000, 40131 bytes)Raspberry Pi support v2 (bug2005.patch, text/plain, 2013-08-29 16:20:22 +0000, 81864 bytes)Raspberry Pi support v3 (bug2005.patch, text/plain, 2013-09-19 12:46:07 +0000, 90384 bytes)Raspberry Pi support v4 (RC) (bug2005.patch, text/plain, 2013-09-26 13:57:33 +0000, 94074 bytes)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:
On 2013-08-01 17:54:04 +0000, Gabriel Jacobo wrote:
On 2013-08-01 18:32:37 +0000, Daniel Bünzli wrote:
On 2013-08-06 20:26:48 +0000, Gabriel Jacobo wrote:
On 2013-08-07 04:19:36 +0000, Sam Lantinga wrote:
On 2013-08-07 22:13:14 +0000, Gabriel Jacobo wrote:
On 2013-08-12 13:06:45 +0000, Joe LeVeque wrote:
On 2013-08-29 16:20:22 +0000, Gabriel Jacobo wrote:
On 2013-08-29 19:39:56 +0000, Aloshi wrote:
On 2013-08-29 20:01:25 +0000, Gabriel Jacobo wrote:
On 2013-08-29 21:01:21 +0000, Aloshi wrote:
On 2013-09-18 22:39:48 +0000, npepinpe wrote:
On 2013-09-19 12:46:07 +0000, Gabriel Jacobo wrote:
On 2013-09-26 13:57:33 +0000, Gabriel Jacobo wrote:
On 2013-09-27 14:59:07 +0000, Gabriel Jacobo wrote:
On 2013-09-28 01:49:19 +0000, Aloshi wrote:
On 2013-09-28 16:38:57 +0000, Gabriel Jacobo wrote:
On 2013-09-28 17:54:38 +0000, Gabriel Jacobo wrote:
The text was updated successfully, but these errors were encountered: