Raspberry PI support

[almostobvious]

Hey there, trying to get this going on RPI.

First, arm binaries are not present in the releases.

The Raspberry PI page here was difficult to follow. The code seems to be set up to build with cmake not make as this page instructs. Neither do the targets PLATFORM_RPI, PLATFORM_DESKTOP or PLATFORM_DRM exist in cmake config.

Since none of the docs provide instructions, I spent a good while trying to work out how to build. If it helps anybody here is what I got to (not claiming it's correct!):

cmake -DPLATFORM="DRM" -DOPENGL_VERSION="ES 2.0" -DGLFW_BUILD_X11=OFF -DGLFW_BUILD_WAYLAND=ON ..

For those wanting to run X
cmake -DPLATFORM="Raspberry Pi" ..

So yes, docs are decidedly unhelpful. Then there is this page with a gem like "raylib is self-contained, it has no external dependencies to build it.". Of course to build on rpi there are stacks of dependencies - and cmake (the way it's configured) will only let you know of missing deps one at a time. So you need to run cmake to get the next missing dependency. Then install it. Then run cmake again. Then install. And again. And again...

After I finally got it to build, all examples fail to run with messages like:

INFO: DISPLAY: No graphic card set, trying platform-gpu-card
INFO: DISPLAY: Failed to open platform-gpu-card, trying card1
INFO: DISPLAY: Failed to open graphic card1, trying card0
WARNING: DISPLAY: Failed to open graphic card
WARNING: TEXTURE: Failed to load texture
WARNING: TEXTURE: Failed to load default texture

As an aside, java wrappers don't bundle arm libs either.

So is RPI supported or not? If yes, where can I find binaries or instructions on how to build?

[asdqwe]

[almostobvious]

Hey thanks very much. I can build now (DRM) thanks to your instructions, but if I try to run I get the following error:

INFO: Initializing raylib 5.6-dev
INFO: Platform backend: NATIVE DRM
INFO: Supported raylib modules:
INFO:     > rcore:..... loaded (mandatory)
INFO:     > rlgl:...... loaded (mandatory)
INFO:     > rshapes:... loaded (optional)
INFO:     > rtextures:. loaded (optional)
INFO:     > rtext:..... loaded (optional)
INFO:     > rmodels:... loaded (optional)
INFO:     > raudio:.... loaded (optional)
INFO: DISPLAY: No graphic card set, trying platform-gpu-card
INFO: DISPLAY: Failed to open platform-gpu-card, trying card1
INFO: DISPLAY: Failed to open graphic card1, trying card0
WARNING: DISPLAY: No suitable DRM connector found
WARNING: TEXTURE: Failed to load texture
WARNING: TEXTURE: Failed to load default texture
WARNING: SHADER: [ID 0] Failed to compile vertex shader code
WARNING: SHADER: [ID 0] Failed to compile fragment shader code
WARNING: SHADER: [ID 0] Failed to link shader program
WARNING: SHADER: [ID 0] Failed to load default shader
INFO: RLGL: Render batch vertex buffers loaded successfully in RAM (CPU)
INFO: RLGL: Render batch vertex buffers loaded successfully in VRAM (GPU)
INFO: RLGL: Default OpenGL state initialized successfully
WARNING: TEXTURE: Failed to load texture
INFO: FONT: Default font loaded successfully (224 glyphs)
INFO: SYSTEM: Working Directory: /opt/lib/raylib/examples
INFO: TIMER: Target time per frame: 16.667 milliseconds
INFO: SHADER: [ID 0] Default shader unloaded successfully
INFO: TEXTURE: [ID 0] Default texture unloaded successfully
INFO: Window closed successfully

There is an issue here, but there doesn't seem to be a clear resolution. I've tried the suggested options with no luck.

If the example works for you, could you possibly share your /boot/config.txt and /boot/firmware/cmdline.txt to check if there is some config I am missing. Could you also let me know what is the output of following commands:

cat /proc/version
ls -l /dev/dri/
ls -l /dev/dri/by-path/

On my Debian 12.2.0-14 based raspbian, this produces:

pi@piwi:/dev/dri/by-path $ cat /proc/version
Linux version 6.6.51+rpt-rpi-v8 (serge@raspberrypi.com) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08)

pi@piwi:/dev/dri/by-path $ ls -l /dev/dri/
total 0
drwxr-xr-x  2 root root         80 Jan 18 16:26 by-path
crw-rw----+ 1 root video  226,   0 Jan 18 14:54 card0
crw-rw----+ 1 root render 226, 128 Jan 18 14:54 renderD128


pi@piwi:/dev/dri/by-path $ ls -l /dev/dri/by-path/
total 0
lrwxrwxrwx 1 root root  8 Jan 18 14:54 platform-soc:gpu-card -> ../card0
lrwxrwxrwx 1 root root 13 Jan 18 14:54 platform-soc:gpu-render -> ../renderD128

As the code is looking for platform-gpu-card, then card1, then card0 (all in /dev/dri/by-path/) I've tried creating links (e.g. sudo ln -s /dev/dri/card0 /dev/dri/by-path/) but this didn't help either.

Just to eliminate a problem with permissions, I've also tried running the example as root without luck.

Many thanks

[almostobvious]

Hurray! The problem was in /boot/config.txt.

I had dtoverlay=vc4-kms-v3d line in there for some reason. When I changed to dtoverlay=vc4-fkms-v3d thanks to this thread, I was able to get the demo to run.

Many thanks

[almostobvious]

EDIT: I was wrong. Setting dtoverlay=vc4-(f)kms-v3d has no bearing.

In my case, I have just one very small screen (480x320) and it seems examples expect window size that is larger my screen size which causes the executable to bail with messages as in my previous post.

Proposed fix : make a check for this and before exiting the program, issue a message that it's exiting because it the screen is smaller than requested window size.

[raysan5]

I think user is the owner of hardware and should be responsibly of it, not raylib.

[orcmid]

@raysan5 @almostobvious

I think user is the owner of hardware and should be responsibly of it, not raylib.

It seems to me this situation is more subtle than that and extends to all situations where a raylib-based app is distributed to others who run it on a configuration where there is insufficient screen real estate versus what the app requires.

However, knowing the available screen dimensions in pixels depends on platform APIs and other display characteristics not visible through raylib. This has to be figured out prior to InitWindow() when an alternative small-enough InitWindow could be used for reporting that the app can't operate and must be cancelled..

I think is too late to have InitWindow() return a failure code, although that would make checking much simpler for the app builder. Consequently, if the built raylib app is to be distributed for a particular platform, it falls to the app implementor to build appropriate defensive code into the app outside of raylib.

[ilacc1]

My 2p - not a huge deal, it is a bit of a niche problem.

It would be nice to have an accurate error report when something so dramatically goes wrong. In my case, this held my handbrake for a day or two as I was debugging various other things - I did not suspect it could be the example code at issue because error was quite explicit - "Failed to open graphic card". So arguably, if the library expects app developers to do InitWindow(0,0) and check screen size perhaps the examples should do that too?

[raysan5]

@almostobvious As comented, the Wiki is not always up to date and I didn't reviewed the Raspberry Pi page in some time. But definitely raylib works on Rapsberry Pi, on PLATFORM_DESKTOP mode (Linux) and also over the kernel on PLATFORM_DRM mode.

EDIT: Thank you very much for reviewing the Wiki and adding that line.