All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>, Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media <linux-media@vger.kernel.org>, workshop-2011@linuxtv.org
Subject: Re: [Workshop-2011] RFC: V4L2 API ambiguities
Date: Mon, 13 Aug 2012 21:15:58 +0200	[thread overview]
Message-ID: <5029526E.7020605@gmail.com> (raw)
In-Reply-To: <5028FD7E.1010402@redhat.com>

Hi!

On 08/13/2012 03:13 PM, Hans de Goede wrote:
>> 2) If a driver supports only formats with more than one plane, should
>> V4L2_CAP_VIDEO_CAPTURE still be defined?
> 
> No

Agreed.

>> And if a driver also supports
>> single-plane formats in addition to >1 plane formats, should
>> V4L2_CAP_VIDEO_CAPTURE be compulsary?
> 
> Yes, so that non multi-plane aware apps keep working.

There is the multi-planar API and there are multi-planar formats. Single- 
and multi-planar formats can be handled with the multi-planar API. So if 
a driver supports single- and multi-planar formats by means on multi-planar
APIs, there shouldn't be a need for signalling V4L2_CAP_VIDEO_CAPTURE, 
which normally indicates single-planar API. The driver may choose to not 
support it, in order to handle single-planar formats. Thus, in my opinion 
making V4L2_CAP_VIDEO_CAPTURE compulsory wouldn't make sense. Unless the 
driver supports both types of ioctls (_mplane and regular versions), we 
shouldn't flag V4L2_CAP_VIDEO_CAPTURE. 

Regards,
Sylwester

  parent reply	other threads:[~2012-08-13 19:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-13 12:27 RFC: V4L2 API ambiguities Hans Verkuil
2012-08-13 13:13 ` [Workshop-2011] " Hans de Goede
2012-08-13 14:52   ` Hans Verkuil
2012-08-13 14:58     ` Hans de Goede
2012-08-13 15:09   ` Ilyes Gouta
2012-08-13 19:15   ` Sylwester Nawrocki [this message]
2012-08-14  8:13     ` Hans de Goede
2012-08-14  0:00   ` Laurent Pinchart
2012-08-14  8:15     ` Hans de Goede
2012-08-13 16:09 ` Rémi Denis-Courmont
2012-08-13 20:27 ` Walter Van Eetvelt
2012-08-13 21:31   ` Devin Heitmueller
2012-08-13 21:39     ` Mauro Carvalho Chehab
2012-08-13 21:42       ` Devin Heitmueller
2012-08-13 21:55         ` Mauro Carvalho Chehab
2012-08-13 23:54 ` [Workshop-2011] " Laurent Pinchart
2012-08-14 10:54   ` Hans Verkuil
2012-08-14 11:06     ` Laurent Pinchart
2012-08-14 11:11       ` Hans Verkuil
2012-08-14 11:15         ` Laurent Pinchart
2012-08-14 11:32           ` Hans Verkuil
2012-08-14 11:42             ` Laurent Pinchart
2012-08-14 21:14               ` Guennadi Liakhovetski
2012-08-14 22:10                 ` Laurent Pinchart
2012-08-14 12:43     ` Hans de Goede
2012-08-14 12:44       ` Chinmay V S

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=5029526E.7020605@gmail.com \
    --to=sylvester.nawrocki@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=workshop-2011@linuxtv.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.