MMAL 64bit support

[6by9]

Placeholder so that people can be made aware that MMAL is currently NOT SUPPORTED on 64 bit userland systems

#586 did add it, but it's been reverted due to issues seen where the a buffer was returned with a context value that had already been released.
At a guess it's a race condition, but it's not obvious exactly where.

This is not a particularly high priority to resolve at present.
Please look towards V4L2 M2M devices for video codecs and the ISP, bcm21835-unicam and libcamera for camera support, or bcm2835-camera/bcm2835-v4l2 for the legacy camera stack.

[pelwell]

For the avoidance of wasted time, "me too" reports and complaints will be deleted.

[lurch]

People can read more about libcamera here (which also has links to additional documentation).

[nikitalita]

Hmm, it appears that ubuntu's aarch64 port for raspi (at least 21.04) never applied the patches that reverted those commits; userland seems to be compiled with this and is working on there? You can see in the source and the patches: http://ports.ubuntu.com/ubuntu-ports/pool/main/r/raspberrypi-userland/

edit: to be clear, "working" in the sense that it isn't blowing up the OS with it compiled and enabled; I have not been able to get ffplay (compiled with --enable-mmal) to decode with h264_mmal, and I don't have a camera so I can't test the other examples.

[pelwell]

@6by9's comment about a "race condition" shows that the issue(s) are of a runtime nature, not a simple build error.

[6by9]

We do have a working relationship with Canonical for Ubuntu. They have chosen to not take the revert, but that is their choice, mainly as it gets PiCamera largely working - their choice, their overhead.

However there are known to be (runtime) issues which we saw on the 32bit builds as much as the 64bit ones, and these mainly were revealed with video decode. Until all of those are resolved, 64bit will not be supported.

[nikitalita]

We do have a working relationship with Canonical for Ubuntu. They have chosen to not take the revert, but that is their choice, mainly as it gets PiCamera largely working - their choice, their overhead.

However there are known to be (runtime) issues which we saw on the 32bit builds as much as the 64bit ones, and these mainly were revealed with video decode. Until all of those are resolved, 64bit will not be supported.

To be sure; I was just wondering if they had something going on in their stack that would prevent the runtime errors or if they just decided to YOLO it. I'm guessing it's the latter.

[waveform80]

To be sure; I was just wondering if they had something going on in their stack that would prevent the runtime errors or if they just decided to YOLO it. I'm guessing it's the latter.

While I wouldn't put it quite that way (I can't ;), I am aware that the vast majority of Ubuntu downloads are for the arm64 arch so having at least some (imperfect) support for the camera module is rather important there. The "right" solution is obviously move stuff like picamera over to libcamera (or more likely come up with something picamera-esque with a libcamera base) and other higher level stuff over to v4l2 but that's a long term project and my plate's already looking full this cycle.

At some point obviously we'll have to bump our userland to the latest version, and remove all support for MMAL-based stuff on arm64, but I'd like to have some replacement for various things (like raspistill, raspivid, and picamera) ready in the distro when we do and that's not quite the case yet.

[lurch]

@waveform80 I've not looked at them myself (so have no idea how functional they are), but perhaps you'd like to provide testing / feedback to https://github.com/raspberrypi/libcamera-apps ?

[dinapappor]

I know there is the "me too" comments etc, but I am quite frustrated.

My development pretty much halted with my stuff because

1. libcamera python bindings are non-documented, (I'd be happy to try to use it if it was somehow documented).
2. I kind of do not want to use picamera2 as it pulls in pyqt, py-numpy and other dependencies I do not want or need. It's also well, obviously not as mature as picamera.

Is it possible to get this working somehow using bullseye (with 64 bit). ?

I'd gladly donate swedish craft beer for this.

[JamesH65]

This would involve a lot of work on a firmware system that we have moved away from, so unlikely to get much traction. All our development effort is in moving to open source systems.

picamera2 is getting pretty good now, worth a second look.

[6by9]

As noted in the first post, #586 did implement the framework required, but there seemed to be some weird path where we received a buffer from the firmware that no longer had a mapping.
That's all open source code in this repo, so feel free to undo the revert and see if it covers your use case.

[Daasin]

I know you guys said it's not high priority but is there any update on this getting fixed by any chance? 😅

I have a weird use case that seems to need picamera specifically but get libmmal.so - no such file issues

[lurch]

I have a weird use case that seems to need picamera specifically but get libmmal.so - no such file issues

I think you'll need to update to use Picamera2 https://www.raspberrypi.com/documentation/computers/camera_software.html#python-bindings-for-libcamera
I believe MMAL is now unsupported on both 64-bit and 32-bit.

[JamesH65]

This will not be fixed. We have moved away from MMAL completely and now use standard Linux APIs, specifically libcamera for anything camera-related.