Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Stefan Kost <ensonic@hora-obscura.de>]

Hans de Goede schrieb:
>
>
> On 06/05/2009 09:43 AM, Stefan Kost wrote:
>> Hans de Goede schrieb:
>>>
>>> On 06/01/2009 09:58 AM, Trent Piepho wrote:
>>>> On Mon, 1 Jun 2009, Stefan Kost wrote:
>>>>> I have implemented support for V4L2_MEMORY_USERPTR buffers in
>>>>> gstreamers
>>>>> v4l2src [1]. This allows to request shared memory buffers from
>>>>> xvideo,
>>>>> capture into those and therefore save a memcpy. This works great with
>>>>> the v4l2 driver on our embedded device.
>>>>>
>>>>> When I was testing this on my desktop, I noticed that almost no
>>>>> driver
>>>>> seems to support it.
>>>>> I tested zc0301 and uvcvideo, but also grepped the kernel driver
>>>>> sources. It seems that gspca might support it, but I ave not
>>>>> confirmed
>>>>> it. Is there a technical reason for it, or is it simply not
>>>>> implemented?
>>>> userptr support is relatively new and so it has less support,
>>>> especially
>>>> with driver that pre-date it.  Maybe USB cams use a compressed format
>>>> and
>>>> so userptr with xvideo would not work anyway since xv won't support
>>>> the
>>>> camera's native format.  It certainly could be done for bt8xx, cx88,
>>>> saa7134, etc.
>>> Even in the webcam with custom compressed format case, userptr support
>>> could
>>> be useful to safe a memcpy, as libv4l currently fakes mmap buffers, so
>>> what
>>> happens  is:
>>>
>>> cam>direct transfer>  mmap buffer>libv4l format conversion>  fake mmap
>>> buffer
>>>> application-memcpy>  dest buffer
>>> So if libv4l would support userptr's (which it currently does not
>>> do) we
>>> could still safe a memcpy here.
>> Do you mean that if a driver supports userptr and one uses libv4l
>> instead of the direct ioctl, there is a regression and the app iuppo
>> getting told only mmap works?
>
> Yes, this was done this way for simplicity's sake (libv4l2 is complex
> enough at is). At the time this decision was made it was an easy one to
> make as userptr support mostly was (and I believe still is) a paper
> excercise. Iow no applications and almost no drivers support it. If
> more applications start supporting it, support can and should be
> added to libv4l2. But this will be tricky.
E.g. omap2 v4l2 drivers (e.g. used in Nokia N800/N810) support it and
the new drivers fro omap3 will do the same. I probably need to revert
the libv4l usage in gstreamer than as we can have regressions in
applications ...
>> For higher pixels counts extra memcpy's
>> are scary, especially if they are no visible. Sorry for the naive
>> question, but what is libv4l role regarding buffer allocations?
>>
>> In ourcase we don't need any extra format conversion from libv4l. I am
>> fine if it works without extra memcpy in that case and I understand that
>> it would be tricky to support inplace formats conversions for some
>> formats and extra memcpy for the rest.
>>> I would be willing to take *clean, non invasive* patches to libv4l
>>> to add
>>> userptr support, but I'm not sure if this can be done in a clean way
>>> (haven't
>>> tried).
>> Where are the libv4l sources hosted. I found your blog and the freshmeat
>> page only so far.
>
> The sources are part of the v4l-dvb mercurial tree. But the latest
> version is in my personal tree, please use that to base patches on:
> http://linuxtv.org/hg/~hgoede/libv4l
Don't count on it. I am quite busy in my current projects :/
Stefan

>
> Regards,
>
> Hans