[SDL] Failed to open vchiq device on RPi

Post by Andreas Falkenhahn
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
* 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?

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

Andreas Falkenhahn

2016-09-02 16:37:56 UTC

I'm assuming you are using Raspbian Jessie.

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

Post by Eric Wing
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

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

--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

Eric Wing

2016-09-02 18:06:14 UTC

Post by Andreas Falkenhahn
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
* 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?

I'm assuming you are using Raspbian Jessie.

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

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

Andreas Falkenhahn

2016-09-11 19:52:51 UTC

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!

Post by Andreas Falkenhahn
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
* 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?

I'm assuming you are using Raspbian Jessie.

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

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

--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

Eric Wing

2016-09-11 22:46:18 UTC

Post by Andreas Falkenhahn
I've looked into this now and the problem is that this call in SDL_egl.c
_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
SDL_VideoInit("RPI");
1) The mouse cursor freezes and I can't move it. Also, keyboard doesn't
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?

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.)

Post by Andreas Falkenhahn
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.

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.)

Post by Andreas Falkenhahn
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?

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

Andreas Falkenhahn

2016-09-12 15:30:05 UTC

Post by Eric Wing
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.

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...

Post by Eric Wing
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.)

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 :(

Post by Eric Wing
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.

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:***@falkenhahn.com

Alex Barry

2016-09-12 16:08:01 UTC

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.)?

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,
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Andreas Falkenhahn

2016-09-12 17:46:53 UTC

Post by Alex Barry
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.)?

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:***@falkenhahn.com

Andreas Falkenhahn

2016-09-12 18:26:34 UTC

Hi Alex,

Out of curiosity, why SDL_PumpEvents if you are calling SDL_PollEvent?

To make this easier I've now written a minimal sample program which
#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
http://www.softwarefailure.de/tmp/sdltest.tar.gz
The archive also contains a build script.
Any help appreciated.
--
Best regards,

--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

Andreas Falkenhahn

2016-09-12 18:34:06 UTC

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.

Out of curiosity, why SDL_PumpEvents if you are calling SDL_PollEvent?

--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

Eric Wing

2016-09-13 01:32:40 UTC

(Sorry, forgot to include list.)

Post by Andreas Falkenhahn
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 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.

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?

Alex Barry

2016-09-13 02:15:12 UTC

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?

Post by Eric Wing
(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.

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?

Gabriel Jacobo

2016-09-13 02:58:49 UTC

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 :)

Post by Alex Barry
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?

Post by Eric Wing
(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.

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?

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

--
Gabriel.

Stuart Axon

2016-09-13 10:00:31 UTC

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 <***@gmail.com> 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 <***@gmail.com>:

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 <***@gmail.com> wrote:

(Sorry, forgot to include list.)

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?

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
***@lists.libsdl.org
http://lists.libsdl.org/listin fo.cgi/sdl-libsdl.org

______________________________ _________________
SDL mailing list
***@lists.libsdl.org
http://lists.libsdl.org/ listinfo.cgi/sdl-libsdl.org

--
Gabriel.

Andreas Falkenhahn

2016-09-13 14:17:37 UTC

Post by Gabriel Jacobo
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 :)

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:***@falkenhahn.com

Andreas Falkenhahn

2016-09-13 14:12:39 UTC

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.

Post by Alex Barry
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?
(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.