[Samsung Galaxy Nexus] Ziyan:
I'm sad to say this, but I have to give up. Generally, I say "never give up", that's what I did with DDK 1.9 & OMX as well, but I'm afraid there's only one solution to our problem: an updated ducati.

Here's what I know about it (with the help of the tuna dev team, especially Hashcode who kindly helped me understanding this mess), though I may be wrong, as this is one of the most complex element of the OMAP architecture:

Generally, ducati is a separate proprietary binary that contains code to the device-specific camera sensors. It controls the M3 processors, which are used for video acceleration. The kernel itself doesn't know about the camera sensors and the M3 processors, it just loads the ducati binary, then userspace can instruct it to send over the camera properties, and begin transmitting the already decoded (accelerated) video. Though video acceleration itself isn't device specific, ducati have to have access to the M3 processors that do the job - while it could communicate with them through the kernel, it would be way slower than having a more direct access to them, so there's very minimal OMX/Camera code in the kernel, most of it is in the ducati binary. Obviously, there's a 3rd layer in the kernel which provides access to the ducati itself for userspace - that's the remoteproc portion of the kernel. It also manages the ION memory allocations, as the accelerated video buffers will be stored in the memory, that's what userspace reads. (There's a high chance this part is wrong, but hopefully you get the idea).

This is where the problem begins. The ducati binary itself is very strict about that memory, it uses ram addresses and stuff like that to allocate it. Obviously, this content has to go through the PVR/DDK driver to get it "displayed" on the screen... however, PVR itself uses ION allocations too. PVR 1.9 needs updated ION allocation methods, it shares some buffers with ducati, etc... so the remoteproc module needs to be updated too, to manage the enhanced allocations with ducati.

The problem is that tuna uses a ducati from late 2011! With it, tuna wins the most outdated ducati binary award, as every OMAP device I found has way more up-to-date ducati that already supports those enhanced ION allocations. Yes, that includes LG omap devices, Samsung omap devices, Amazon omap devices...

Again, this is more complex than this, I tried to write an understandable novel about how it works basically. Don't take it serious, as it may be wrong in some aspects, but it works like that.

tl;dr

ducati has proprietary camera sensor codes

sgx ddk 1.9 requires updated ION buffer allocations

tuna's very very VERY old ducati can't allocate the ION buffers required for camera, as it can't communicate with the updated allocator

Solution: an updated ducati binary. All this would be very easy with it - as you may have understood, the idea itself is pretty nice. Basically, everything related to camera is inside the ducati, userspace/kernel receives the camera output in a generalized format. Imagine that you want to add an extra camera to tuna. All you have to do is add it's sensor code to the ducati, and you're all set, no need for rom/kernel-side changes.

Now getting that updated ducati binary... is a big problem. I'm afraid only Google or Samsung could provide it. If they would at least publish it's sources, that would be already progress.

However, don't worry, I won't retire from tuna. I continue working on the kernel and rom side. With the dev team, we're already testing the updated OMAP kernel (without ddk 1.9), which already a HUGE update over our stock kernel. My first "public" work on tuna is already pushed :victory: https://github.com/omnirom/android_device_samsung_tuna/commits/android-4.4

Edit: wow, this post became a mess too, hope it's understandable :D