public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Trent Piepho <xyzzy@speakeasy.org>
Cc: Stefan Kost <ensonic@hora-obscura.de>, linux-media@vger.kernel.org
Subject: Re: webcam drivers and V4L2_MEMORY_USERPTR support
Date: Mon, 01 Jun 2009 14:54:23 +0200	[thread overview]
Message-ID: <4A23CF7F.3070301@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0906010056140.32713@shell2.speakeasy.net>



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

  parent reply	other threads:[~2009-06-01 12:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01  7:26 webcam drivers and V4L2_MEMORY_USERPTR support Stefan Kost
2009-06-01  7:58 ` Trent Piepho
2009-06-01  8:07   ` Stefan Kost
2009-06-01 12:54   ` Hans de Goede [this message]
2009-06-05  7:43     ` Stefan Kost
2009-06-07 16:01       ` Hans de Goede
2009-06-08  8:58         ` Stefan Kost
2009-06-08 14:54           ` Hans de Goede
2009-06-01 23:12 ` Laurent Pinchart
2009-06-02  5:47   ` Stefan Kost
2009-06-02 11:51   ` Mauro Carvalho Chehab
2009-06-02 12:13     ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A23CF7F.3070301@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=ensonic@hora-obscura.de \
    --cc=linux-media@vger.kernel.org \
    --cc=xyzzy@speakeasy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox