search

raspberrypi / userland

Source code for ARM side libraries for interfacing to Raspberry Pi GPU.
BSD 3-Clause "New" or "Revised" License
2.05k stars 1.09k forks source link

MMAL 64bit support #688

Closed 6by9 closed 1 year ago

6by9 commented 3 years ago

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 commented 3 years ago

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

lurch commented 3 years ago

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

nikitalita commented 3 years ago

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 commented 3 years ago

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

6by9 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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