From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: V4L2 spec / core questions
Date: Sun, 20 Jan 2013 22:15:51 +0100 [thread overview]
Message-ID: <50FC5E87.2080902@googlemail.com> (raw)
Hi Hans,
I noticed that there's code in the v4l2 core that enables/disables
ioctls and checks some of the parameters depending on the device type.
While reading the code an comparing it to the V4L2 API document, some
more questions came up:
1) Video devices with VBI functionality:
The spec says: "To address the problems of finding related video and VBI
devices VBI capturing and output is also available as device function
under /dev/video".
Is that still valid ? What about VBI "configuration" (e.g.
VIDIOC_G/S/TRY_FMT for VBI formats) ?
Looking into the v4l2 core code, it seems that the VBI buffer types
(field "type" in struct v4l2_format) are only accepted, if the device is
a VBI device.
2) VIDIOC_G/S/TRY_FMT and VBI devices:
The sepc says: "VBI devices must implement both the VIDIOC_G_FMT and
VIDIOC_S_FMT ioctl, even if VIDIOC_S_FMT ignores all requests and always
returns default parameters as VIDIOC_G_FMT does. VIDIOC_TRY_FMT is
optional." What's the reason for this ? Is it still valid ?
3) VIDIOC_S_TUNER: field "type" in struct v4l2_tuner
Are radio tuners accessable through video devices (and the other way
around) ?
Has this field to be set by the application ? If yes: driver overwrites
the value or returns with an error if the type doesn't match the tuner
at the requested index ?
I wonder if it would make sense to check the tuner type inside the v4l
core (like the fmt/buffer type check for G/S_PARM).
4) VIDIOC_DBG_G_CHIP_IDENT:
Is it part of CONFIG_VIDEO_ADV_DEBUG just like VIDIOC_DBG_G/S_REGISTER ?
In determine_valid_ioctls(), it is placed outside the #ifdef
CONFIG_VIDEO_ADV_DEBUG section.
The spec says "Identify the chips on a TV card" but isn't it suitable
for all device types (radio/video/vbi) ? determine_valid_ioctls() in
v4l2-dev.c enables it for all devices.
5) The buffer ioctls (VIDIOC_REQBUFS, VIDIOC_CREATE_BUFS,
VIDIOC_PREPARE_BUF, VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF) are not
applicable to radio devices, right ?
In function determine_valid_ioctls() in v4l2-dev.c they are enabled for
all device types.
6) VIDIOC_G/S_AUDIO: Shouldn't it be disabled in
determine_valid_ioctls() for VBI devices ?
Btw: function determine_valid_ioctls() in v4l2-dev.c is a good summary
that explains which ioctls are suitable for which device types
(radio/video/vbi).
Converting its content into a table would be a great
extension/clarifaction of the V4L2 API spec document !
Thanks for your patience !
Regards,
Frank
next reply other threads:[~2013-01-20 21:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 21:15 Frank Schäfer [this message]
2013-01-21 8:59 ` V4L2 spec / core questions Hans Verkuil
2013-01-21 21:25 ` Frank Schäfer
2013-01-21 21:39 ` Hans Verkuil
2013-01-22 18:50 ` Frank Schäfer
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=50FC5E87.2080902@googlemail.com \
--to=fschaefer.oss@googlemail.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.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.