scenic_driver_nerves_rpi
scenic_driver_nerves_rpi copied to clipboard
boydm
Failing to run on RPI 4: DIRTY CLOSE
What version of scenic and scenic_driver_nerves_rpi are you using? Can you provide some logs? That would be helpful in tracking down the problem. Also I don't think anyone has attempted to run Scenic on an RPI 4 yet so you will likely run into some issues getting it to work.
@axelson I'm using scenic: ~> 0.10 and scenic_driver_nerves_rpi: ~> 0.10.
And the logs say nothing really. It seems to work boot normally and everything but it gets stuck. And when you ssh into the device and run RingLogger.next everything seems fine but one line (if you scroll a little bit to the top) that just says: [error]: dirty close.
Another thing I tried to see if I would get something different is stop the application and start it from the iEx session, and as expected I got another message that seems to point to the creation of the window; the message is the following: RPI driver error: Unable create the native window surface.
This points to the line 184 on the c code for the driver when it tries to create the window itself (or so it seems).
Hope this helps.
~ bjufre
So far, I haven't done any work to port the driver to the rpi4. In fact, I don't have an rpi4 yet.
I have some other pressing matters for now, so if anyone wants to take a crack at this, that would be nice. The issues will all be in the initialization functions in main.c. I believe the video circuits on the board have change significantly and it may need a new native window surface strategy. I haven't dug into it yet.
@boydm @axelson found this example as to how to set it up on rpi4: https://github.com/matusnovak/rpi-opengl-without-x
Will try and take a closer look.
~ bjufre
@axelson I have tried the previous comment implementation but so far no luck.
Any ideas from your end?
Sorry, I haven't looked at that portion of scenic's code before so I don't have any ideas at the moment.
From what I've heard the Pi4 has different graphics underpinnings. I know it doesn't provide a framebuffer which hit some of my use-cases in other libraries. I imagine this means some changes in the driver. But most of the OpenGL/drawing stuff should be the same.
I've mostly absorbed some of this from fhunleth, I wouldn't know where to start on a fix but figured I'd mention this.
@axelson, on your first comment you asked providing some log files. I'm pretty new to scenic and nerves env. Is it possible to find a log file that contains whatever printed on the screen?
For now I can only provide a screenshot
Hardware: RPI4 with 4GB, Official Raspberry 7" Display
Yeah. This will likely be pile of work in the main.c file of the driver. The rest of it should be pretty much the same.
I haven't had time to dive into it, but will eventually. If someone else wants to take a crack at at least learning out to initialize OpenGL on the rpi4, that would go a long way. Even getting to the point where it only sets up the display environment, then draws one triangle would be great.
I won't be able to get to this for a while. Am completely swamped with other work. (a good thing!)
Oh. I should add. If the solution is different enough with the code for the RPI0/3, then it should be rolled into a new rpi4+ driver so that the old one still works with minimal hacking.
From some reading the Pi 4 has a more standard initialization. I don't know much about OpenGL but according to some thread, this code should work on Raspbian for the Pi4.
I found that in this weird and confusing thread that does discuss the graphics changes a bit.
Here are the video option docs for config.txt. From my reading the Pi4 is very reliant on edid and having a display plugged in for things to work.
The Pi4 apparently uses the v3d driver for 3D rather than the vc4 driver (which it only uses for DRM/KMS compositing support). Taking this from this thread.
I think we might need to look into whether everything is as it should in the Nerves Pi4 system as well. Assuming people want to use this with Nerves, which seems to be the common case.
I checked the nerves_system_rpi4 and from a fairly uninformed point of view it does seem to have the necessary stuff. I would recommend someone start by just seeing if they can fix the OpenGL initialization.
FYI - This is worth looking at again. nerves_system_rpi4 v1.11.0 (just released) updates the vc4 driver and mesa3d support. I'm not sure on the timing correlates to this issue, but I did learn that at one point nerves_system_rpi4 was including a version of mesa3d that would never have worked. I think the time is good for someone to start writing a scenic_driver_nerves_rpi4 (interest and time-permitting, of course)
Sigh... The irony is that while New Zealand under lockdown (giving me the time to work on this), the stores are closed, so I can't go out and buy an rpi4. Would be fun about now.
Scenic is running fine on rpi4 with raspbian and glfw, maybe there is a way to reuse glfw for nerves setup.
I wish it were that easy. Need to get down into the low-level display surface apis that are set up by raspian. Those dont exist under Nerves, and it is main piece of work that needs to happen.
I'd like to assist this issue, because I also hope that Scenic supports RasPi 4. I have some knowledge to support GPUs, through development of Pelemay.
I haven't understood the structure of Scenic, because I've just know it by the presentation at ElixirConf EU virtual. Let me know what of source code of Scenic I should read at first.
@zacky1972 this repo is specifically for rendering Scenic on the Pi with Nerves. It implements what Scenic calls a Driver. Which takes the primitives and turns them into something to show on the screen. This Driver uses NanoVG to render which is a library that provides som graphics primitives and renders them with OpenGL.
It currently supports up to Pi3. If you look in the c_src folder you’ll find main.c which is where the driver is initialized. It does some initialization that is specific to the Pi devices if I recall correctly and from my comment further up and fhunleth’s comment about the updates in the Nerves system for Pi 4, I think this could be made to work if you could change how we initialize OpenGL.
Let me know if anything I wrote feels unclear. I would be very happy to see someone do this but I dont have the time right now and am very bad at C ;)
That is exactly right. The way the rpi4 initializes OGL changed. One of these days I'll actually get an rpi4 and maybe make some progress on it, but if anyone else takes a crack at it that would be be great. Basically, you start by making an port (exe) that does nothing. Then slowly build it up so that you draw one triangle. After that triangle shows, it's 90% there...
I'm confused because I heard Scenic on Raspbian works well, though that on Nerves doesn't. I guess porting the initialization of that on Raspbian to that on Nerves will fix this issue. Let me know why not.
Scenic on raspbian works well with the glfw-based driver. If the pi4 system has been updated as fhunleth said, I guess you could try that on Nerves. But I imagine there is still quite a difference in how much graphics-stuff raspbian ships by default compared to nerves.
I was recently pointed to this repository: https://github.com/ardera/flutter-pi. From a skim, it looks like if you delete all of the user input and flutter integration code, that what remains is an example for setting up the display on the RPi4 without using X-Windows or Wayland.
Thank you @fhunleth. That is a great start. (flutter is also something I'm interested in learning more about, so double-win?)
@zacky1972, @lawik and Everyone else: Scenic should work well on raspbian on an rpi4. The issue isn't the OGL calls, it is setting up the low-level graphics drawing planes, hardware windows and such. This work is done by raspbian when it boots up. Scenic on Nerves is much more low-level than that. The scenic rpi driver has to boot the graphics hardware from scratch. On the rpi3, that meant figuring out how graphics chip needed to be initialized. Same will need to be done for the rip4, which has a new graphics pipeline.
Not the easiest work, mostly because it isn't that well documented.