webcam drivers and V4L2_MEMORY_USERPTR support

webcam drivers and V4L2_MEMORY_USERPTR support

[Stefan Kost]

hi,

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?

Thanks
Stefan

[1] http://bugzilla.gnome.org/show_bug.cgi?id=583890

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Trent Piepho]

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.

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Stefan Kost]

Trent Piepho schrieb:
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   
Yes, I am aware of the format issue. On the gstreamer side formats are
negotiated. Plugins export e.g. wat colorpsaces they support and the
zerocopy path can only be taken if e.g. both support UVYV. Luckily this
is quite common.

But thanks for the info. I have nver touched kernel code sofar, but if I
find some free time, I can try to add support for it in one driver.

Stefan

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Hans de Goede]

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.

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).

An alternative could be for the app to just use read() in the above case
as then the app already provides the dest buffer. And the conversion will write
directly to the application provided buffer.

Regards,

Hans

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Laurent Pinchart]

Hi Stefan,

On Monday 01 June 2009 09:26:10 Stefan Kost wrote:
> hi,
>
> 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?

For the uvcvideo driver it's simply not implemented. I was about to give it a 
try when I found out a mismatch between the V4L2 specification and the 
videobuf implementation (which I wanted to use as the reference 
implementation).

The V4L2 specification states, in section 3.3, that

"The driver must be switched into user pointer I/O mode by calling the 
VIDIOC_REQBUFS with the desired buffer type. No buffers are allocated 
beforehands, consequently they are not indexed and cannot be queried like 
mapped buffers with the VIDIOC_QUERYBUF ioctl."

Example 3-2 shows that v4l2_requestbuffers::count is not used when using 
USERPTR.

However, videobuf pre-allocates v4l2_requestbuffers::count kernel-side buffer 
descriptors when VIDIOC_REQBUFS is called with USERPTR.

If someone could clarify which of the V4L2 specification or the videobuf 
implementation is right I could give USERPTR a try in the uvcvideo driver.

Best regards,

Laurent Pinchart

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Stefan Kost]

Laurent Pinchart schrieb:
> Hi Stefan,
> 
> On Monday 01 June 2009 09:26:10 Stefan Kost wrote:
>> hi,
>>
>> 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?
> 
> For the uvcvideo driver it's simply not implemented. I was about to give it a 
> try when I found out a mismatch between the V4L2 specification and the 
> videobuf implementation (which I wanted to use as the reference 
> implementation).
> 
> The V4L2 specification states, in section 3.3, that
> 
> "The driver must be switched into user pointer I/O mode by calling the 
> VIDIOC_REQBUFS with the desired buffer type. No buffers are allocated 
> beforehands, consequently they are not indexed and cannot be queried like 
> mapped buffers with the VIDIOC_QUERYBUF ioctl."
> 
> Example 3-2 shows that v4l2_requestbuffers::count is not used when using 
> USERPTR.
> 
> However, videobuf pre-allocates v4l2_requestbuffers::count kernel-side buffer 
> descriptors when VIDIOC_REQBUFS is called with USERPTR.
> 
I actually noticed the same with our the omap3 camera driver. In userspace I now
call VIDIOC_REQBUFS with V4L2_MEMORY_USERPTR and count=0, if I get EINVAL, try
again with count!=0 and if EINVAL again try V4L2_MEMORY_MMAP (always with
count). I also got feedback from the driver developers, that the buffers are
still indexed and mlocked, so when I DQBUF and QBUF I should enqueue the same
buffers for the same index again.

Stefan

> If someone could clarify which of the V4L2 specification or the videobuf 
> implementation is right I could give USERPTR a try in the uvcvideo driver.
> 
> Best regards,
> 
> Laurent Pinchart
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Mauro Carvalho Chehab]

Em Tue, 2 Jun 2009 01:12:37 +0200
Laurent Pinchart <laurent.pinchart@skynet.be> escreveu:

> Hi Stefan,
> 
> On Monday 01 June 2009 09:26:10 Stefan Kost wrote:
> > hi,
> >
> > 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?
> 
> For the uvcvideo driver it's simply not implemented. I was about to give it a 
> try when I found out a mismatch between the V4L2 specification and the 
> videobuf implementation (which I wanted to use as the reference 
> implementation).
> 
> The V4L2 specification states, in section 3.3, that
> 
> "The driver must be switched into user pointer I/O mode by calling the 
> VIDIOC_REQBUFS with the desired buffer type. No buffers are allocated 
> beforehands, consequently they are not indexed and cannot be queried like 
> mapped buffers with the VIDIOC_QUERYBUF ioctl."
> 
> Example 3-2 shows that v4l2_requestbuffers::count is not used when using 
> USERPTR.
> 
> However, videobuf pre-allocates v4l2_requestbuffers::count kernel-side buffer 
> descriptors when VIDIOC_REQBUFS is called with USERPTR.
> 
> If someone could clarify which of the V4L2 specification or the videobuf 
> implementation is right I could give USERPTR a try in the uvcvideo driver.

It is better to assume that videobuf is right and fix the API spec. Videobuf is
there since kernel 2.4 and not much changed on it, in terms of its operational
mode. 

So, the existing applications assume videobuf behaviour. Any change would break
existing apps.

So, it is better to fix the API spec to reflect the practical implementation.



Cheers,
Mauro

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Laurent Pinchart]

Hi Mauro,

On Tuesday 02 June 2009 13:51:03 Mauro Carvalho Chehab wrote:
> Em Tue, 2 Jun 2009 01:12:37 +0200
>
> Laurent Pinchart <laurent.pinchart@skynet.be> escreveu:
> > Hi Stefan,
> >
> > On Monday 01 June 2009 09:26:10 Stefan Kost wrote:
> > > hi,
> > >
> > > 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?
> >
> > For the uvcvideo driver it's simply not implemented. I was about to give
> > it a try when I found out a mismatch between the V4L2 specification and
> > the videobuf implementation (which I wanted to use as the reference
> > implementation).
> >
> > The V4L2 specification states, in section 3.3, that
> >
> > "The driver must be switched into user pointer I/O mode by calling the
> > VIDIOC_REQBUFS with the desired buffer type. No buffers are allocated
> > beforehands, consequently they are not indexed and cannot be queried like
> > mapped buffers with the VIDIOC_QUERYBUF ioctl."
> >
> > Example 3-2 shows that v4l2_requestbuffers::count is not used when using
> > USERPTR.
> >
> > However, videobuf pre-allocates v4l2_requestbuffers::count kernel-side
> > buffer descriptors when VIDIOC_REQBUFS is called with USERPTR.
> >
> > If someone could clarify which of the V4L2 specification or the videobuf
> > implementation is right I could give USERPTR a try in the uvcvideo
> > driver.
>
> It is better to assume that videobuf is right and fix the API spec.
> Videobuf is there since kernel 2.4 and not much changed on it, in terms of
> its operational mode.
>
> So, the existing applications assume videobuf behaviour. Any change would
> break existing apps.
>
> So, it is better to fix the API spec to reflect the practical
> implementation.

Ok, fine with me.

Cheers,

Laurent Pinchart

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Stefan Kost]

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 is
getting told only mmap works? 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.
>
> An alternative could be for the app to just use read() in the above case
> as then the app already provides the dest buffer. And the conversion
> will write
> directly to the application provided buffer.
The driver in question support streaming. Isn't that the better way to
do it.
>
> Regards,
>
> Hans
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Hans de Goede]

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.

> 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

Regards,

Hans

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Stefan Kost]

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

Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Hans de Goede]

Hi all,

On 06/08/2009 10:58 AM, Stefan Kost wrote:
> 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 ...

Erm the current (0.10.15) gstreamer libv4l2 plugin does not even use
USERPTR support (which confirms my I didn't implement it because
nothing uses it reasoning), so there can be no regression.

Now not using libv4l will make gstreamer applications not work with
*hundreds* of different webcam models (and that is not an exageration),
see:
http://moinejf.free.fr/webcam.html

For an incomplete list, now some there may work without libv4l, but most
don't.

So given as a choice:
* not having a performance enhancement, which was never present before
   so no regression
* not working with *hundreds* of different webcam models

Which one are you going to choose ? I will most certainly know
where to redirect the bug reports.

Regards,

Hans