allegro5
allegro5 copied to clipboard
liballeg
Dedicated RPI code hangs while creating display on an RPI4
See https://www.allegro.cc/forums/thread/618023.
I could reproduce it, but only if I used raspi-config to disable the OpenGL desktop driver (otherwise I got a 'device already in use' error).
Disabling the OpenGL driver - on a PI4 - is basically disabling any GL capabilities for the system. The old/legacy GL drivers are not supported anymore on the PI4 - you need to enable the new GL driver if you intend to make use of GL(ES) on the system. Note that the driver is enabled by default on a Pi4 (via /boot/config.txt).
The 'device already in use' error means it tries to initialize GL(ES) using the old/legacy driver, which is no longer supported (or working) on a PI4.
Interesting! So I wonder if the error in the thread is caused by the OpenGL driver not being enabled in Buster Lite, which means that there's technically nothing to do on our end.
On the PI4, the (new) Mesa OpenGL/OpenGLES driver is enabled by default on all variants of Raspbian (Lite or Desktop). It has to be explicitly disabled in order to get that error message (which you did by using raspi-config).
From a GL(ES) perspective, the Pi4 should work similar to a normal DRM/KMS supporting GPU system (Intel/AMD) with an open source MESA driver.
Yes, I think there's nothing wrong with the Allegro library - I've compiled it on a Pi4 and it works fine.
Some more random links about this:
https://www.raspberrypi.org/forums/viewtopic.php?t=243707 https://www.raspberrypi.org/forums/viewtopic.php?t=243892 https://www.raspberrypi.org/forums/viewtopic.php?t=255478
The goal is to compare performance of running OpenGL with and without X11. Maybe there's a way to update the dedicated RPI code to use the new style, and have it be backwards compatible with RPI3.
The current plan is to investigate https://gitlab.freedesktop.org/mesa/kmscube to see how they do it. I managed to run kmscube on my RPI4 without X and got OpenGL. Their code looks superficially like A5's dedicated RPI backend, but unlike A5's code, it appears to work alright. The way I tested is that I booted RPI to CLI and ran the application.
... don't suppose you guys have had any time to look at this again by any chance?
I spent a bunch of time on this recently, without much headway. I got A5 code to get past the offending function, but that required gutting a lot of the code. In particular, I had to remove all of the Broadcom-specific functions and use regular GLES combined with libgbm. That to me indicates (with relatively low confidence, since I understand very little) that we basically need to rewrite the entire backend to use DRM + regular GLES, like kmscube does.
...sounds like a bit of a nightmare to me. I've really appreciated the time you've spent looking at it though. Thank you. I do hope this isn't the end of the line for Allegro on RPi; they're a great combination :(
Cheers Mike
Thank you. I do hope this isn't the end of the line for Allegro on RPi; they're a great combination :(
But Allegro works on the Pi - you just need to compile it with X11 support and use it an X11 env.
Thanks for the info, but I want to run it on Buster lite (not desktop), which as far as I understand is without X11? If I'm wrong and it can be run on Lite please I'd love to have more specific details (i.e. what I exactly need to do to get it going).
Many thanks Mike
Thanks for the info, but I want to run it on Buster lite (not desktop), which as far as I understand is without X11
Yes, that's correct. You can't run it right now without an X11 env - on the Pi4 model. Hardly an 'end of the line' though, for Allegro on the Pi.
That's great news :)
Sorry for my ignorance, but going back to my very original question on this post, when I run my app it hangs. Siegelord has spent some time investigating, but you are saying it works, so I'm obviously building it incorrectly. Can you advise please? (Just a build / cmake command would be enough I guess)
Thanks again Mike
That's great news :)
I think you mis-understood my previous reply
You can't run it right now without an X11 env - on the Pi4 model.
As @SiegeLord said, without re-implementing a KMS/DRM/EGL video backend that would work outside X11, it's not going to work for the Pi 4 as it works for the previous Pi models (using the Broadcom legacy video drivers).
Ah sorry, misread your comment. So it won't work for me. I've gone around in a circle :( I do hope you guys will have the time to sort this out but I'll understand if it's not a priority. Real shame if not. Thankfully pi3's are continuing to be made and sold for the foreseeable future.
Keep up the great work...Allegro has been a fantastic library for me.
Cheers Mike
Just to be clear, I still will try to get it to work. It's not like RPI backend is that large, it's completely conceivable to rewrite it. It's just it'll take a little bit of time to do so.
Some progress on this, I got mode switching to work but currently no graphics are displayed, hah.
@SiegeLord FWIW you can take a look at SDL's kmsdrm video driver if you need inspiration (and use Allegro with SDL backend for testing - I think I successfully tried it in the past)
I'd love to see a native kmsdrm driver in Allegro - but that is the easier part. What we need is a way to compile multiple backends into a single binary, just like SDL does - so you can switch between X11, KMS and Wayland at runtime. I'd be glad to work on and maintain KMS and Wayland backends, but reworking Allegro to allow for multiple backends seemed too overwhelming to me...
Hi! I recently rewrote the KMSDRM backen in SDL2 for ATOMIC KMSDRM interfacing. You can see the new code here:
https://hg.libsdl.org/SDL/file/6c2bbcfc3940/src/video/kmsdrm
Ask me whatever you need, I'd be glad to answer :) But please, please! Bring allegro to X-less Pis! There are many good games wrote for it, that fit the Pi. Also, you don't happen to have a Vulkan backend in Allegro, do you? Because I am adding X-less Vulkan support, and Vulkan has just started working on the Pi without X (KHR_Display extension), so that would do, too.
@vanfanel SWe don't have a Vulkan backend yet, no. Since you are skillfull in Vulkan and KMSDRM backends, perhaps you could also implement those for Allegro 5? It would be much appreciated.
@beoran The problem is that I don't know allegro internals. It has to be done by someone knowing his way in allegro. It's a VERY time consuming task otherwise, and I don't have much time these days.
Well, we are willing willing to coach you on that point, but if you lack the time, we'll probably have to crib the SDL drivers and convert them to Allegro...
I have gone back to non-ATOMIC because using the ATOMIC functions broke compatibility for a lot of old cards.
@SiegeLord Are you still working on this? Can I help you somehow? The latest version of the KMSDRM backend for SDL2 is here now: https://github.com/libsdl-org/SDL/tree/main/src/video/kmsdrm
Are you able to show graphics already on allegro using KMSDRM?
Hi
Just want to let you guys know that I'm still very keen to see this happen. Appreciate all that you're doing.
Cheers Mike
@chundermike It's good to be keen, it's better to contribute if you can. The Allegro internals are not that hard to get to know.
I managed to get graphics working today, with some lingering segfaults; sadly, I discovered that the keyboard input doesn't work, so I need to explore what needs to be done there.
That's great news so far. I know it's not finished, but is there a branch I can grab to have a play sometime? I'm not bothered about the input issues as I use my own drivers for that.
Here's the WIP branch: https://github.com/SiegeLord/allegro5/tree/rpi4_gbm
You compile it via:
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-raspberrypi.cmake -DWANT_X11=off