Grabber crashing on startup

[Chaphasilor]

Hi, I just tried to get this to run, but unfortunately the program crashed after a few seconds.
Here's the backtrace I managed to record:
all.log

I seems like it can't access the video planes/buffers for some reason.

Here's my environment:

• Raspberry Pi 4 (4 GB), running the OSMC beta for Raspberry Pi 4
• hyperion-ng 2.0.0-alpha.9
• Installed rust using curl https://sh.rustup.rs -sSf | sh and then setting the default host triple to armv7-unknown-linux-gnueabihf like it is in the readme.
  I had to overwrite the default value, which would've been aarch64-unknown-linux-gnu.
• Installed the linter and built the binary using the commands provided in the readme
• Executed the binary after build and got the above logs

Any idea what's causing this? I believe you are also using a Pi4 running OSMC, did you make any extra modifications?

[rudihorn]

Will check the log later, but did you make sure to run it as root?

[Chaphasilor]

Yes, I was root the whole time. For all installations, compilation and execution. Hyperion is also running as root, for better or worse...

[rudihorn]

Hmm so I am actually using a 2B+ but assumed this would work on a Pi 4. The fact that the DRM API is crashing is even stranger, but I suspect it might be due to authentication issues.

Part of the problem seems to be that the Pi2 uses the VC4 driver while the Pi4 uses the V3D driver, but looking at the APIs they are quite similar so getting the buffer mapping part to work should be easy. But because it is crashing before it gets to the driver specific code this might be more problematic.

I have rearranged the code a bit so it tries to capture the CRTCs first, if you could see if this still crashes using the DRM API that would be great.

Sadly I don't have a Pi 4 where I am to try this out :(

[rudihorn]

Looking at it root automatically becomes authenticated with the VC4 driver. The just uploaded version also checks this flag, so if you could check the result of that by sending new logs that would help to tell if thats the issue.

[Chaphasilor]

Testing it now :)

[Chaphasilor]

all.log

Behavior seems to be mostly the same, sadly.
I also noticed there's some CLI argument parsing going on, do I need to pass some arguments? Until now I've always just ran ./drm-v4-capture, but I guess that should also work, given that you've defined default values...

[rudihorn]

yeah that should work fine. Interestingly yours says its authenticated, but still fails to do much. I assume the latest commit which tries to authorize didn't fix it though?

[Chaphasilor]

I assume the latest commit which tries to authorize didn't fix it though?

Nope, my cloned repo was fully up-to-date before I re-compiled everything 😕

[rudihorn]

Hmm not even too sure why this is happening then. The code for kodi essentially does the same thing (https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/drm/DRMUtils.cpp), calling drmModeGetResources and if that failed it wouldn't start. Could you post the log for when kodi is stopped?

[Chaphasilor]

I will try, although it seems to me that getting the log is a bit involved, or am I missing something?

[Chaphasilor]

@rudihorn all.log
Error seems to be the same with Kodi stopped

I was confused at first and thought you wanted Kodi's log file to check how they do it, so I also got that file in case you want to take a look at it :)

[0x6470]

I experienced a similar behaviour.
Also on a RPi 4 with OSMC and freshly built hyperion-ng.
The error message is not quite the same, though:

• with Kodi running: with_kodi.txt
• without Kodi running: without_kodi.txt

Hope, this helps.

[rudihorn]

Thanks for the logs both of you! Yes seems to be the issue isn't Kodi locking the DRM hardware. I'm wondering if it is an issue that one needs to open up a render node or something instead. Could you please output the contents of sudo ls -R /dev/drm? I might need to disect more of what drmGetDevices2 does...

[0x6470]

Of course I can do help you with that.
There doesn't seem to be a drm "device" in my case:

root@osmc:/opt/hyperion# sudo ls -R /dev/drm
ls: cannot access '/dev/drm': No such file or directory

Maybe that's already the culprit.
However, here is the output of ls -R /dev/ : dev.txt

[rudihorn]

Thanks! I was actually looking for the entries in /dev/dri and your output includes them. It seems your device for some reason has two /dev/dri/cardX entries. I'm also a bit confused because your log indicates that your pi is using the vc4 driver instead of the v3d driver... Either way I've just updated the codebase so you should be able to specify the device path. Could you see if sudo ./drm-v4-capture -d /dev/dri/card1 or sudo ./drm-v4-capture -d /dev/dri/renderD128 does anything different?