All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Walls <awalls@md.metrocast.net>
To: Andre Draszik <v4l2@andred.net>
Cc: linux-media@vger.kernel.org
Subject: Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs
Date: Sat, 22 May 2010 11:35:06 -0400	[thread overview]
Message-ID: <1274542506.2255.55.camel@localhost> (raw)
In-Reply-To: <AANLkTineD8GCtG1OD4WQahW7zS23IxQDx7XmnAsrVSqs@mail.gmail.com>

On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
> Hi,
> 
> As per the spec, the above ioctl codes are defined for inputs only -
> it would be useful if there were similar codes for outputs.
> 
> I therefore propose to add the following:
> 
> VIDIOC_G_OUTPUT_STD
> VIDIOC_S_OUTPUT_STD
> VIDIOC_ENUM_OUTPUT_STD
> 
> which would behave similar to the above, but for output devices.
> 
> Thoughts?

Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD.

>From what I see:

ivtv/ioctl.c
zoran/zoran_driver.c
davinci/vpif_display.c

all use VIDIOC_S_STD for setting the output standard.

Note that the v4l2_subdev video_ops have a "s_std_output" method which
is what you can grep for in the code to verify for yourself.


Some thoughts:

1. to me it appears that the ivtv driver looks like it ties the output
standard to the input standard currently (probably due to some firmware
limitation).  This need not be the case in general.

2. currently the ivtv driver uses sepearte device nodes for input device
and an output device.  If bridge drivers maintain that paradigm, then
separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed.

3. ENUMSTD is currently handled by the v4l2 core in v4l2-ioctl.c with no
hook for bridge drivers.  The bridge drivers were all getting it wrong
in some way or another for enumerating stanadrds on the input.

4. What's the harm in letting S_STD fail for an unsupported standard on
an output?  An application usually doesn't have much choice but to fail,
if the hardware doesn't support the user's desired standard.
ENUMSTD_OUTPUT for outputs seems superfulous.  If you had an
ENUM_STD_OUTPUT ioctl() to call, an application will either find the
desired standard in the list and know S_STD should succeed, or it won't
an will assume S_STD will fail.  From an application writing
perspective, it seems like less work for the application to just detect
when S_STD fails.


Regards,
Andy


  reply	other threads:[~2010-05-22 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-22 14:06 VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs Andre Draszik
2010-05-22 15:35 ` Andy Walls [this message]
2010-05-22 17:21   ` Ian Armstrong
2010-05-23 11:20     ` Hans Verkuil
2010-05-23 17:32       ` Andre Draszik
2010-05-23 18:33       ` Ian Armstrong
  -- strict thread matches above, loose matches on Subject: below --
2010-05-22 13:46 Andre Draszik

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=1274542506.2255.55.camel@localhost \
    --to=awalls@md.metrocast.net \
    --cc=linux-media@vger.kernel.org \
    --cc=v4l2@andred.net \
    /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.