Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18 May 2018 at 16:05, Mauro Carvalho Chehab
<mchehab+samsung@xxxxxxxxxx> wrote:
> Em Fri, 18 May 2018 15:27:24 +0300
<snip>
>>
>> > There, instead of an USB camera, the hardware is equipped with a
>> > MC-based ISP, connected to its camera. Currently, despite having
>> > a Kernel driver for it, the camera doesn't work with any
>> > userspace application.
>> >
>> > I'm also aware of other projects that are considering the usage of
>> > mc-based devices for non-dedicated hardware.
>>
>> What are those projects ?
>
> Well, cheap ARM-based hardware like RPi3 already has this issue: they
> have an ISP (or some GPU firmware meant to emulate an ISP). While
> those hardware could have multiple sensors, typically they have just
> one.

Slight hijack, but a closely linked issue for the Pi.
The way I understand the issue of V4L2 / MC on Pi is a more
fundamental mismatch in architecture. Please correct me if I'm wrong
here.

The Pi CSI2 receiver peripheral always writes the incoming data to
SDRAM, and the ISP is then a memory to memory device.

V4L2 subdevices are not dma controllers and therefore have no buffers
allocated to them. So to support the full complexity of the pipeline
in V4L2 requires that something somewhere would have to be dequeuing
the buffers from the CSI receiver V4L2 device and queuing them to the
input of a (theoretical) ISP M2M V4L2 device, and returning them once
processed. The application only cares about the output of the ISP M2M
device.

So I guess my question is whether there is a sane mechanism to remove
that buffer allocation and handling from the app? Without it we are
pretty much forced to hide bigger blobs of functionality to even
vaguely fit in with V4L2.

I'm at the point where it shouldn't be a huge amount of work to create
at least a basic ISP V4L2 M2M device, but I'm not planning on doing it
if it pushes the above buffer handling onto the app because it simply
won't get used beyond demo apps. The likes of Cheese, Scratch, etc,
just won't do it.


To avoid ambiguity, the Pi has a hardware ISP block. There are other
SoCs that use either GPU code or a DSP to implement their ISP.

  Dave



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux