linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [GIT PULL FOR 3.6] V4L2 API cleanups
Date: Thu, 05 Jul 2012 17:55:27 -0300	[thread overview]
Message-ID: <4FF5FF3F.6030909@redhat.com> (raw)
In-Reply-To: <4FD50223.4030501@iki.fi>

Em 10-06-2012 17:22, Sakari Ailus escreveu:
> Hi Mauro,
> 
> Here are two V4L2 API cleanup patches; the first removes __user from
> videodev2.h from a few places, making it possible to use the header file
> as such in user space, while the second one changes the
> v4l2_buffer.input field back to reserved.
> 
> 
> The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181:
> 
>    [media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24
> 09:27:24 -0300)
> 
> are available in the git repository at:
>    ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6
> 
> Sakari Ailus (2):
>        v4l: Remove __user from interface structure definitions

>        v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT

Indeed, no drivers use V4L2_BUF_FLAG_INPUT, although I think this should be
used there, for some devices.

There are several surveillance boards (mostly bttv boards, but there are
also cx88 and saa7134 models in the market) where the same chip is used 
by up to 4 cameras. What software does is to switch the video input
to sample one of those cameras on a given frequency (1/60Hz or 1/30Hz),
in order to collect the streams for the 4 cameras.

Without an input field there at the buffer metadata, it might happen that 
software would look into the wrong input.

That's said, considering that:

1) no driver is currently filling buffer queue with its "inputs" field,
   this flag is not used anywhere;

2) an implementation for input switch currently requires userspace to tell
   Kernel to switch to the next input, with is racy;

3) a model where the Kernel itself would switch to the next input would
   require some Kernelspace changes.

I agree that we can just remove this bad implementation. If latter needed,
we'll need to not only reapply this patch but also to add a better way to
allow time-sharing the same video sampler with multiple inputs.

So, I'll apply this patch.

Regards,
Mauro

  parent reply	other threads:[~2012-07-05 20:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-10 20:22 [GIT PULL FOR 3.6] V4L2 API cleanups Sakari Ailus
2012-06-11  7:50 ` Laurent Pinchart
2012-06-11  9:39   ` Sakari Ailus
2012-06-16 22:03     ` Laurent Pinchart
2012-06-17  7:54       ` Sakari Ailus
2012-06-18 10:53         ` Laurent Pinchart
2012-07-05 20:46     ` Mauro Carvalho Chehab
2012-07-06  8:51       ` Laurent Pinchart
2012-07-05 20:55 ` Mauro Carvalho Chehab [this message]
2012-07-05 21:21   ` Sakari Ailus
2012-07-05 21:31     ` Ezequiel Garcia
2012-07-05 22:27       ` Mauro Carvalho Chehab
2012-07-05 21:41     ` Mauro Carvalho Chehab

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=4FF5FF3F.6030909@redhat.com \
    --to=mchehab@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@iki.fi \
    /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;
as well as URLs for NNTP newsgroup(s).