The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I've compiled SDL 2.0.4 on my Raspberry Pi 2 (running Raspbian) and followed all
the instructions in docs/README-raspberrypi.md. However, it doesn't work. I always
get the following error:

* failed to open vchiq device

I've googled the error and tried all the solutions I could find (e.g. doing a
"sudo chmod 777 /dev/vchiq" or adding user pi to the video group by doing
"sudo usermod -a -G video pi") but nothing helped. I still get the error.

What is causing this and how can I fix this?

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 9/1/16, Andreas Falkenhahn wrote:

I'm assuming you are using Raspbian Jessie.

I don't remember having to do anything special on my Pi that required
privileged access (besides cranking up the amount of GPU memory). But
I have a pretty boring Pi setup. (Just the basic with a HDMI into a
TV. No cameras or touch screen, etc.)

Does my demo program work for you?
http://playcontrol.net/tempdownload/BlurrrBinaries/FlappyBlurrrC-0.1.1-Raspbian.tar.gz

Run the ./FlappyBlurrrC
Everything should be self-contained. I ship my own copy of SDL with it.


-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 01.09.2016 at 20:43 Eric Wing wrote:







I'm still on Wheezy but AFAIR that should be ok.



Yes, it works. What could be the reason that my build doesn't work?

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 9/2/16, Andreas Falkenhahn wrote:

Could be a thousand things, but my first guess is you installed a
bunch of stuff on your system, which in turn changes SDL's automatic
dependency phase in configure or whatever, and SDL builds with
different features which may not work or may require extra
permissions. You may need to vette every build option when you build
SDL. (For example, I recall a touch library to be problematic and I
think I disabled it explicitly.)


Or you could use Blurrr

FYI, the demo program is from a new SDK I'm developing, centered
around SDL. One of the things Blurrr offers is shipping prebuilt
libraries vetted to work for distribution on multiple platforms,
saving you from this stuff. Blurrr tries to give you a
download-and-go, non-root, reproducible way of developing for
cross-platform, so you can focus on your game instead of building
dependencies and managing different build systems on every platform.

https://blurrrsdk.com

Thanks,
Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I've looked into this now and the problem is that this call in SDL_egl.c
returns NULL:

_this->egl_data->egl_display = _this->egl_data->eglGetDisplay(native_display);

I've then examined further and found out that SDL2 was actually using the
X11 video driver. I'd have expected it to use the RPI driver instead. So
I did the following:

SDL_VideoInit("RPI");

Now it finally worked - well, sort of. There are still some issues:

1) The mouse cursor freezes and I can't move it. Also, keyboard doesn't
seem to work. According to the docs, this should solve it:

sudo usermod -aG input pi

But it didn't. Input doesn't seem to work at all and the mouse cursor is
locked in the top left corner of the screen. Does anybody have an idea why
this happens?

2) What about the X11 driver? Is it supposed to work on the Pi or do
I have to use the RPI driver on the Pi? As I said, using the X11 driver
results in a "Failed to open vchiq device" error message.

3) I've noticed that the RPI driver always opens in full screen mode. Is
it also possible to make this open in window mode?

Thanks!

On 02.09.2016 at 20:06 Eric Wing wrote:






















--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 9/11/16, Andreas Falkenhahn wrote:

I mentioned during the SDL 2.0.4 release cycle I was seeing an
SDL_assert being thrown in the mouse system sometimes. In further
testing, it seems to happen to me when the system is loaded down and
cannot complete the event loop in a reasonable amount of time. If you
kill your process (i.e. remote login), maybe you'll see that this is
the same assertion being thrown prompting you to abort/ignore.

Unfortunately, as you've seen, SDL's Pi implementation goes directly
to the framebuffer and bypasses everything else. The keyboard input is
also affected by this which is why you can't send a response to the
SDL_assert. (The easiest workaround is to disable SDL_assert when
compiling it.)


When the SDL implementation was written, Pi only had a GLES driver and
the Pi could not support rendering through X11. (Apparently there is
some scary hack that Minecraft figured out which makes it kind of
work, but still is pretty wonky.)


Pi released a "beta" of a full blown OpenGL driver earlier this year.
It is still experimental. I have not tried it. One of its goals was to
allow applications run through the window server. Another of its goals
was to allow the vast amount of desktop OpenGL Linux software to run
on Pi without change.

If you install and enable this driver, and configure SDL
appropriately, maybe you can get this to work. I don't know what's
actually involved to make this work. I would like to hear your results
and the procedure for making this work.

One thing to keep in mind is it sounds like the OpenGL driver is much
more heavy weight than the ES driver. I've heard this number but not
verified: expect to consume 300MB of RAM which is a sizable chunk of
the 1GB you have.


-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 12.09.2016 at 00:46 Eric Wing wrote:


I've compiled with

#define SDL_ASSERT_LEVEL 0

and I've also killed the process from a remote machine using SSH to
look at the output but there is none! SDL doesn't show anything. My
program runs correctly using SDL on the Pi but it can't be used because
the mouse cursor is frozen and keyboard doesn't work either This is
quite frustrating... any other ideas? Without input support it's obviously
pretty useless...


This of course makes me wonder why the RPI driver isn't selected as the
default driver when building for the Pi? It took me an hour to figure out
what was going wrong until I realized that I had to call

SDL_VideoInit("RPI");

in order to make it work. Why does SDL select the X11 driver as the
default driver when building for the Pi when it obviously doesn't
work? This should really be fixed and there should be a word about
it in the readme. Currently, there is none. There are several
pages about cross-compiling for the Pi but the essentials are missing
it seems


I better first get the RPI driver working correctly here before
tackling even more experimental stuff... what else can I try to
get input working?

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I'm going to get by Pi2 back up and running this weekend, so I don't mind taking a peek at what's going on.  Do you have your project online anywhere or are you just using a bare-bones sort of project (ie single fullscreen window taking input.)?

On Mon, Sep 12, 2016 at 11:30 AM, Andreas Falkenhahn wrote:

On 12.09.2016 at 18:08 Alex Barry wrote:


To make this easier I've now written a minimal sample program which
shows the issue. Here it is:

#include <SDL.h>

int main(int argc, char *argv[])
{
SDL_Window *window;
SDL_Renderer *renderer;
SDL_Texture *texture;
SDL_Event se;
int quit = 0;
int bufferwidth = 1920, bufferheight = 1080;
char *pixbuf = malloc(bufferwidth * bufferheight * 4);

SDL_Init(SDL_INIT_VIDEO);
SDL_VideoInit("RPI");

window = SDL_CreateWindow("Foo", 0, 0, bufferwidth, bufferheight, SDL_WINDOW_FULLSCREEN);
renderer = SDL_CreateRenderer(window, -1, 0);
texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STREAMING, bufferwidth, bufferheight);

memset(pixbuf, 0, bufferwidth * bufferheight * 4);
SDL_UpdateTexture(texture, NULL, pixbuf, bufferwidth * 4);
SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderPresent(renderer);

SDL_ShowWindow(window);
SDL_RaiseWindow(window);

while(!quit) {

SDL_PumpEvents();

while(SDL_PollEvent(&se)) {
if(se.type == SDL_MOUSEBUTTONDOWN) quit = 1;
}
}

SDL_DestroyTexture(texture);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);

SDL_Quit();

free(pixbuf);

return 0;
}

I've also prepared a package containing a ready-to-run binary as well as my
build of SDL 2.0.4 for the Pi. This can be downloaded from here:
http://www.softwarefailure.de/tmp/sdltest.tar.gz

The archive also contains a build script.

Any help appreciated.

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi Alex,

On 12.09.2016 at 19:54 Alex Barry wrote:







--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sorry, my last mail was empty.

Yes, SDL_PumpEvents() is redundant of course. It's just there because I did lots of
tests because I thought the event loop somehow didn't work correctly because
the mouse cursor locked and keyboard didn't work. I also tried SDL_WaitEvents()
and various combinations but nothing helped. Quite frustrating

Anyway, removing SDL_PumpEvents() from the loop doesn't change anything.
It still doesn't work.

On 12.09.2016 at 19:54 Alex Barry wrote:







--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

(Sorry, forgot to include list.)


I don't remember, but I do remember seeing multiple sources
recommending to disable X11 when building SDL. This avoids most
problems and doesn't require any changes to your project code like
adding SDL_VideoInit("RPI");

In general, the problem with building on Pi is that it looks just like
any other Linux system from a build process perspective. Linux
Standard Base is the easiest way to start making these queries, but
Raspbian doesn't install LSB. Something still could be done, but most
I'm sure nobody felt like doing it. And since the Pi foundation is
trying to make it work like any regular Linux desktop, this mechanism
will ultimately conflict with that.



So, that program I sent you at the beginning, does input work there?
Can you take that libSDL that I shipped and use it with your program
instead of the one I built? Does input work?

If mine works, you still probably have a build configuration issue.

-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Although I agree with you, Sam's buildbot script seems to indicate that maybe you do need those extra configure options; https://hg.libsdl.org/SDL/file/default/build-scripts/raspberrypi-buildbot.sh#l44

Sam, if you have a free minute this weekend, can you confirm or deny this?


On Mon, Sep 12, 2016 at 9:32 PM, Eric Wing wrote:

I can confirm you should disable those if you happen to have the corresponding dev headers installed, and most certainly disable X11 if you want to avoid headaches. When configure ends you should only see the Raspberry pi video driver (and the dummy one) for the most painless experience...and also, don't be running X11 on the RPi when you try your apps

2016-09-12 23:15 GMT-03:00 Alex Barry:




--
Gabriel.

I'm curious - what will happen when running these SDL apps under X11 on Raspberry pi?


S++



On Tuesday, September 13, 2016 3:58 AM, Gabriel Jacobo wrote:

Oops, sorry for the confusion. It turned out to be my fault. I did a clean install
of Jessie last weekend to see if the problems were related to Wheezy which I was
running before that. Because I was so focused on getting the "Failed to open vchiq device"
error solved I then simply forgot to install the packages

libudev-dev libdbus-1-dev

after the upgrade to Jessie I've done that now and surprise, surprise: Input
is working now. So sorry for the false alert.

But I still think that SDL should select the RPI driver as the default on the PI.
Since cmake/configure automatically select this driver for building, I assume
that there must be a way to detect a Pi and then enable this driver.

If it really isn't possible to automatically detect a Pi, then you could also
add a new option for cmake/configure that specifically configures the build for
the Pi. Of course such an option should be mentioned in the README-raspberrypi.md
then.

On 13.09.2016 at 04:15 Alex Barry wrote:










--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 13.09.2016 at 04:58 Gabriel Jacobo wrote:


Um, I'm not a Linux expert. So how exactly am I supposed to run SDL
apps on the Pi if not from X11? I currently run them from X11 and
it works but I've noticed that the Raspbian desktop is still alive
beneath the framebuffer locked by SDL and the desktop can even be
controlled, e.g. I can drag windows around or even close them, start
programs etc. Nothing is visible of course because SDL has taken over
the framebuffer but the desktop is still functioning beneath the
framebuffer which is certainly quite weird...

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org