/dev/dri on piCore12.0

[runningopenloop]

Hello,

I think I'm trying to get /dev/dri to populate?

I've got an SDL2 application I'm working on and trying to make run on piCore 12.0.  I had started with piCore13.03 but as per:
http://forum.tinycorelinux.net/index.php?topic=24762.0
http://forum.tinycorelinux.net/index.php/topic,24855.msg159683.html#msg159683
It appears piCore13.03 doesn't yet work for SDL applications.  Before I saw these messages I tried piCore13.03 and was getting errors that /dev/dri could not be opened.

So trying again with piCore12.0.$ uname -a
Linux box 5.4.51-piCore #1 Sat Sep 19 11:11:32 EDT 2020 armv6l GNU/Linux

Note I'm not running X, here's my onboot.lst.
openssh.tcz
compiletc.tcz
rpi-vc.tcz
rpi-vc-dev.tcz
SDL2-dev.tcz
SDL2_image.tcz
SDL2_image-dev.tcz
SDL2_gfx.tcz
graphics-5.4.51-piCore.tcz
squashfs-tools.tcz


   > I made the SDL2_gfx tcz.
   > I was hoping graphics-5.4.51-piCore would make things work, but no.

I am running on a old RpiB1
$ cat /proc/cpuinfo
processor    : 0
model name    : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 697.95
Features    : half thumb fastmult vfp edsp java tls
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2835
Revision    : 0002
Serial        : 00000000bc3f268b
Model        : Raspberry Pi Model B Rev 1

Here is my cmdline.txt, I tried without vga=791 also:zswap.compressor=lz4 zswap.zpool=z3fold console=tty1 root=/dev/ram0 elevator=deadline rootwait quiet nortc loglevel=3 noembed multivt vga=791

I've tried with and without the following line in config.txt.  Otherwise config.txt is stock. (sounds like I may actually not want to do this).
dtoverlay=vc4-fkms-v3d                                                       


----

Currently my issue is that when I run my application, video fails to initialize.  With piCore12.0 I don't get errors about /dev/dri, but SDL_GetError says there is no available video device.  Here's my video init snippet and the resulting output.


    int numRenderDrivers = SDL_GetNumRenderDrivers();
    printf( "%d render drivers:\n", numRenderDrivers );
    for( int i = 0; i < numRenderDrivers; ++i )
    {                     
        SDL_RendererInfo rendererInfo;
        SDL_GetRenderDriverInfo(i, &rendererInfo);
        printf("Render driver %d: ", i );           
        PrintRendererInfo(rendererInfo);               
    }                                         
                         
    SDL_Init(SDL_INIT_VIDEO);         
                                                 
    cout << "SDL Init done" << endl;                 
                                                       
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
                                                     
    win = SDL_CreateWindow("Test", 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_OPENGL | SDL_WINDOW_FULLSCREEN_DESKTOP);


I get this output:

4 render drivers:
Render driver 0: Renderer: opengl software=0 accelerated=1, presentvsync=1 targettexture=1
Render driver 1: Renderer: opengles2 software=0 accelerated=1, presentvsync=1 targettexture=1
Render driver 2: Renderer: opengles software=0 accelerated=1, presentvsync=1 targettexture=0
Render driver 3: Renderer: software software=1 accelerated=0, presentvsync=0 targettexture=1
SDL Init done
Failed to create SDL Window
SDL Error = >No available video device<

---

Any guidance would be appreciated.
modprobe vc4 does load some modules, but no /dev/dri is populated.

• Doesn't change the fact the application doesn't work and SDL_GetError returns No available video device.
• It seems strange to me that it is listing a video drivers.. but then doesn't work.
• I've run this code on arch linux and it works.

73

[Juanito]

The sdl2 extension has been updated recently on both piCore and piCore64 13.x.

I've tested ffplay, which uses sdl2, successfully on both piCore and piCore64 13.x - albeit on RPi3/RPi4 and using x11/wayland

Using dtoverlay=vc4-kms-v3d{,-pi4} and loading graphics-KERNEL gives:

Code: [Select]

[RPi3]
$ ls /dev/dri*
card0       renderD128
[RPi4]
$ ls /dev/dri*
card0       card1       renderD128

[runningopenloop]

Thanks for the note Juanito.  I've not quite made progress yet.  However I think the root issue for me using SDL2 is not the /dev/dri drivers existing.  But rather, it seems that SDL could have been compiled without support the RPI driver.

Setting SDL_VIDEODRIVER=RPI doesn't seem to work.  I may still be missing something here, but is it possible to know with what drivers SDL has been compiled?
  I thought the code snippet I'm using above would have told me, and I think want to use the opengles2.

However this thread: https://stackoverflow.com/questions/57672568/sdl2-on-raspberry-pi-without-x
shows someone's configure resulting in this list:
 Video drivers   : dummy rpi x11(dynamic) kmsdrm(dynamic) opengl opengl_es1 opengl_es2 vulkan wayland(dynamic)

So it has opengl_es2 and rpi.

https://wiki.libsdl.org/FAQUsingSDL
I've also tried some of these, as might be expected, I did get XDG_RUNTIME_DIR directory missing with starting with SDL_VIDEODRIVER=x11 (or was it wayland)... which is expected since I don't have X installed.

I've been trying to compile it myself on the RPi, but I've been getting errors which sound like out of memory errors for the compiler.
  > I guess my next attempt will be to cross-compile with RPi driver enabled.

In the meantime, is it possible to confirm that the picore12 and picore13 SDL don't have RPI driver enabled somehow?

73,
Timothy

[Juanito]

Here are the details for the compilation: http://tinycorelinux.net/13.x/armv7/tcz/src/sdl2/compile_sdl2

[Juanito]

Ah - I see the rpi driver requires the closed source stuff in rpi-vc-dev.

Given that mesa, etc is compiled for the open source video drivers, I'm not sure how they would play together.

Maybe you could compile sdl2 locally using rpi-vc-dev and --enable-video-rpi in addition to the build notes linked above and see if it works?

[runningopenloop]

That's what I'll try to do, BTW - should I be able to cross compile with the RPI target if I stick the rpi-vc-dev on my cross compiling machine?

As for compiling on my raspberry pi, I was having issues with memory and compiling SDL.  Perhaps I need to load the modules not using the tce-load so it doesn't go into memory.  I suppose the best thing would be to do an unsquash-fs so the files write to the appropriate paths, then they will just be in place and not in memory.

If I get this to work out, is there a process which I might submit an SDL2-vc package?  I think this sort of info was on the wiki but it seems not available now.

73,
Timothy

[Rich]

Hi runningopenloop
If you want to save memory, make sure you unpack your source package(s) and do your compiling in a directory
that exists on your SD card or USB device.

If you are working in  /tmp  you are in RAM.
If you are working in  /home/tc  and your home directory is not persistent, you are in RAM.

If you need to make a persistent directory to work out of:

Code: [Select]

sudo mkdir /mnt/mmcblk0p2/DirName
sudo chown tc:staff /mnt/mmcblk0p2/DirName

... Perhaps I need to load the modules not using the tce-load so it doesn't go into memory.  I suppose the best thing would be to do an unsquash-fs so the files write to the appropriate paths, then they will just be in place and not in memory. ...

That will make it worse. Modules contained in extensions go into  /usr/local/lib/modules/KERNEL-piCore/kernel/  which
is in RAM. When tce-load loads an extension, it creates soft links from the modules in the squashfs to that directory.
On my x86 systems (TC4 and TC10) those links only occupy 100 to 120 bytes of RAM each.
The modules themselves still reside in the extension which is on persistent storage, your  tce  directory.

... If I get this to work out, is there a process which I might submit an SDL2-vc package?  I think this sort of info was on the wiki but it seems not available now.

If you are considering submitting an extension, Instructions can be found here:
https://web.archive.org/web/20200208152109/http://wiki.tinycorelinux.net/wiki:creating_extensions#submitting

Use the  tcesubmit  email address, not the  picoresubmit  address.

[Juanito]

In fact sdl-2.0.16 and the latest git will not compile with "--enable-video-rpi", see: https://github.com/libsdl-org/SDL/issues/4514

There is an ubuntu patch for this, but then the build fails with a different problem.

[runningopenloop]

Hm, so my update is I compiled SDL2-2.0.16
./configure reported
Video drivers: dummy rpi opengl_es1 opengl_es2 vulkan
...
Using libsamplerate: NO
Using libudev: NO
Using dbus: NO
Using ime: YES
Using ibus: NO
Using fcitx: NO

However now I get the error when using RPI driver: "SDL_Init(): The video driver did not add any displays"

I did update my code to print out driver info too (as per https://forums.raspberrypi.com/viewtopic.php?t=315565)
  BTW, when I run on the SDL2 provided with piCore12.0, as expected - no RPI.  X11 was in the list.  Don't recall the other details.

So here is my current output:

2 video drivers:
Video driver 0: RPI
Video driver 1: dummy

3 render drivers:
Render driver 0: Renderer: opengles2 software=0 accelerated=1, presentvsync=1 targettexture=1
Render driver 1: Renderer: opengles software=0 accelerated=1, presentvsync=1 targettexture=0
Render driver 2: Renderer: software software=1 accelerated=0, presentvsync=0 targettexture=1
SDL Init done: returned -1
Error message: The video driver did not add any displays

Not sure at the moment the next best step or how to best debug.

I do have:
/dev/loop1 on /tmp/tcloop/libGLES type squashfs (ro,relatime)
/dev/loop2 on /tmp/tcloop/libEGL type squashfs (ro,relatime)
/dev/loop3 on /tmp/tcloop/rpi-vc type squashfs (ro,relatime)

I notice rpi-vc contains:
squashfs-root/usr/local/lib/libEGL.so
squashfs-root/usr/local/lib/libGLESv1_CM.so
squashfs-root/usr/local/lib/libGLESv2.so
squashfs-root/usr/local/lib/libOpenVG.so

and libEGL contains:
squashfs-root/usr/local/lib/libEGL.so
squashfs-root/usr/local/lib/libEGL.so.1
squashfs-root/usr/local/lib/libEGL.so.1.0.0

and libGLES contains:
squashfs-root/usr/local/lib/libGLESv1_CM.so
squashfs-root/usr/local/lib/libGLESv1_CM.so.1
squashfs-root/usr/local/lib/libGLESv1_CM.so.1.1.0
squashfs-root/usr/local/lib/libGLESv2.so
squashfs-root/usr/local/lib/libGLESv2.so.2
squashfs-root/usr/local/lib/libGLESv2.so.2.0.0

So this seems wrong to include the libGLES and libEGL with rpi-vc.  Juanito, perhaps this is what you were warning me about earlier.  However removing libEGL/libGLES from my onboot.lst didn't make any difference.

I guess my next step would be to look at the SDL2 code to see what this not adding any displays error is from.

Or my I may try using the framebuffer for graphics as a short term solution.

Thanks to all for the help so far.

73,
Timothy

[Juanito]

Maybe the first step is to check that:

/tmp/tcloop/rpi-vc/usr/local/lib/libEGL.so -> /usr/local/lib/libEGL.so
/tmp/tcloop/rpi-vc/usr/local/lib/libGLESv1_CM.so -> /usr/local/lib/libGLESv1_CM.so
/tmp/tcloop/rpi-vc/usr/local/lib/libGLESv2.so -> /usr/local/lib/libGLESv2.so
/tmp/tcloop/rpi-vc/usr/local/lib/libOpenVG.so -> /usr/local/lib/libOpenVG.so

..and not the libEGL or libGLES extensions.

[runningopenloop]

Mission effectively accomplished!

Looking for why the error of "The video driver did not add any displays" showed up in
https://github.com/libsdl-org/SDL/blob/main/src/video/raspberry/SDL_rpivideo.c
seemed to indicate a failure to the vc_dispmanx_display_open call.

https://github.com/juj/fbcp-ili9341/issues/100
Suggested that setting hdmi_group=2, hdmi_mode=??, and hdmi_force_hotplug=1 in the config.txt may solve the issue.  I already had the hdmi_force_hotplug, but added the hdmi_group=2 and hdmi_mode=83 for my 1600x900 60 Hz screen... and it worked!
  - Now my keyboard doesn't allow me to ctrl+C break from my program and the mouse doesn't appear to respond... maybe some SDL input handling issues, but it looks like I've made it over the hill!

Thanks much.  So I think all I should need in my onboot.lst is:
rpi-vc.tcz
git.tcz
SDL2.tcz  (I re-compiled this with RPi driver).
SDL2_image.tcz
SDL2_gfx.tcz   (I compiled this).

If I were to submit a package for SDL, I suppose the best thing to do would be to build SDL2 with *all* the drivers vs. one SDL2 for RPi and one for X11/other.  Don't think I'll be able to manage that in the near future, but perhaps I could submit an SDL2_gfx.

Thanks again.

73,
Timothy

[Juanito]

I'd suggest you name your sdl2 rpi extension SDL2-rpi, which would have a dep on rpi-vc - that way we keep the existing SDL2 extension, which is everything except rpi-vc and SDL2-rpi, which is only rpi-vc.

Since sdl2-gfx is not in the repo, please go ahead and submit it - I take it that it doesn't depend on rpi-vc?

[runningopenloop]

I think that is the only tricky part.  SDL2_image and SDL2_gfx would then depend on either SDL2 or SDL2-rpi.  Is there a way to handle that?

[Juanito]

Unfortunately there isn't a way to fix that.

There's also another problem in that, if libEGL is loaded before rpi-vc, the symlink /tmp/tcloop/libEGL/usr/local/lib/libEGL.so -> /usr/local/lib/libEGL.so will not be overwritten by /tmp/tcloop/rpi-vc/usr/local/lib/libEGL.so -> /usr/local/lib/libEGL.so.