From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Hans Verkuil <hansverk@cisco.com>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans Verkuil <hans.verkuil@cisco.com>
Subject: Re: [PATCH 2/3] media: videodev2: add a flag for vdev-centric devices
Date: Fri, 25 Aug 2017 08:15:03 -0300 [thread overview]
Message-ID: <20170825081503.13e4df80@vento.lan> (raw)
In-Reply-To: <d118d078-429b-5ea4-02d1-8852c7c662f2@xs4all.nl>
Em Fri, 25 Aug 2017 12:56:30 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 25/08/17 12:50, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Aug 2017 12:42:51 +0200
> > Hans Verkuil <hansverk@cisco.com> escreveu:
> >
> >> On 08/25/2017 12:35 PM, Mauro Carvalho Chehab wrote:
> >>> Em Fri, 25 Aug 2017 12:13:53 +0200
> >>> Hans Verkuil <hansverk@cisco.com> escreveu:
> >>>
> >>>> On 08/25/2017 12:06 PM, Mauro Carvalho Chehab wrote:
> >>>>> Em Fri, 25 Aug 2017 11:44:27 +0200
> >>>>> Hans Verkuil <hansverk@cisco.com> escreveu:
> >>>>>
> >>>>>> On 08/25/2017 11:40 AM, Mauro Carvalho Chehab wrote:
> >>>>>>> From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> >>>>>>>
> >>>>>>> As both vdev-centric and mc-centric devices may implement the
> >>>>>>> same APIs, we need a flag to allow userspace to distinguish
> >>>>>>> between them.
> >>>>>>>
> >>>>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> >>>>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >>>>>>> ---
> >>>>>>> Documentation/media/uapi/v4l/open.rst | 6 ++++++
> >>>>>>> Documentation/media/uapi/v4l/vidioc-querycap.rst | 4 ++++
> >>>>>>> include/uapi/linux/videodev2.h | 2 ++
> >>>>>>> 3 files changed, 12 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/media/uapi/v4l/open.rst b/Documentation/media/uapi/v4l/open.rst
> >>>>>>> index a72d142897c0..eb3f0ec57edb 100644
> >>>>>>> --- a/Documentation/media/uapi/v4l/open.rst
> >>>>>>> +++ b/Documentation/media/uapi/v4l/open.rst
> >>>>>>> @@ -33,6 +33,12 @@ For **vdev-centric** control, the device and their corresponding hardware
> >>>>>>> pipelines are controlled via the **V4L2 device** node. They may optionally
> >>>>>>> expose via the :ref:`media controller API <media_controller>`.
> >>>>>>>
> >>>>>>> +.. note::
> >>>>>>> +
> >>>>>>> + **vdev-centric** devices should report V4L2_VDEV_CENTERED
> >>>>>>
> >>>>>> You mean CENTRIC, not CENTERED.
> >>>>>
> >>>>> Yeah, true. I'll fix it.
> >>>>>
> >>>>>> But I would change this to MC_CENTRIC: the vast majority of drivers are VDEV centric,
> >>>>>> so it makes a lot more sense to keep that as the default and only set the cap for
> >>>>>> MC-centric drivers.
> >>>>>
> >>>>> I actually focused it on what an userspace application would do.
> >>>>>
> >>>>> An specialized application for a given hardware will likely just
> >>>>> ignore whatever flag is added, and use vdev, mc and subdev APIs
> >>>>> as it pleases. So, those applications don't need any flag at all.
> >>>>>
> >>>>> However, a generic application needs a flag to allow them to check
> >>>>> if a given hardware can be controlled by the traditional way
> >>>>> to control the device (e. g. if it accepts vdev-centric type of
> >>>>> hardware control).
> >>>>>
> >>>>> It is an old desire (since when MC was designed) to allow that
> >>>>> generic V4L2 apps to also work with MC-centric hardware somehow.
> >>>>
> >>>> No, not true. The desire is that they can use the MC to find the
> >>>> various device nodes (video, radio, vbi, rc, cec, ...). But they
> >>>> remain vdev-centric. vdev vs mc centric has nothing to do with the
> >>>> presence of the MC. It's how they are controlled.
> >>>
> >>> No, that's not I'm talking about. I'm talking about libv4l plugin
> >>> (or whatever) that would allow a generic app to work with a mc-centric
> >>> device. That's there for a long time (since when we were reviewing
> >>> the MC patches back in 2009 or 2010).
> >>
> >> So? Such a plugin would obviously remove the MC_CENTRIC cap. Which makes
> >> perfect sense.
> >>
> >> There are a lot of userspace applications that do not use libv4l. It's
> >> optional, not required, to use that library. We cannot design our API with
> >> the assumption that this library will be used.
> >>
> >>>
> >>>>
> >>>> Regarding userspace applications: they can't check for a VDEV_CENTRIC
> >>>> cap since we never had any. I.e., if they do:
> >>>>
> >>>> if (!(caps & VDEV_CENTRIC))
> >>>> /* unsupported device */
> >>>>
> >>>> then they would fail for older kernels that do not set this flag.
> >>>>
> >>>> But this works:
> >>>>
> >>>> if (caps & MC_CENTRIC)
> >>>> /* unsupported device */
> >>>>
> >>>> So this really needs to be an MC_CENTRIC capability.
> >>>
> >>> That won't work. The test should take into account the API version
> >>> too.
> >>>
> >>> Assuming that such flag would be added for version 4.15, with a VDEV_CENTRIC,
> >>> the check would be:
> >>>
> >>>
> >>> /*
> >>> * There's no need to check version here: libv4l may override it
> >>> * to support a mc-centric device even for older versions of the
> >>> * Kernel
> >>> */
> >>> if (caps & V4L2_CAP_VDEV_CENTRIC)
> >>> is_supported = true;
> >>>
> >>> /*
> >>> * For API version lower than 4.15, there's no way to know for
> >>> * sure if the device is vdev-centric or not. So, either additional
> >>> * tests are needed, or it would assume vdev-centric and output
> >>> * some note about that.
> >>> */
> >>> if (version < KERNEL_VERSION(4, 15, 0))
> >>> maybe_supported = true;
> >>
> >>
> >> is_supported = true;
> >> if (caps & V4L2_CAP_MC_CENTRIC)
> >> is_supported = false;
> >> if (version < KERNEL_VERSION(4, 15, 0))
> >> maybe_supported = true;
> >>
> >> I don't see the difference. BTW, no application will ever do that version check.
> >> It doesn't help them in any way to know that it 'may' be supported.
> >
> > Yeah, this can work. The only drawback is that, if we end by
> > implementing vdev compatible support is that such drivers will
> > have to clean the V4L2_CAP_MC_CENTRIC flag.
>
> You mean implementing vdev compatible support in libv4l? (Just making sure
> I understand you correctly)
Yes, either there or at the Kernel, as it seems we'll never have it
there, as nobody is working on it anymore.
> In that case it doesn't matter if the libv4l code would set the VDEV_CENTRIC flag
> or remove the MC_CENTRIC flag. That makes no difference, or course.
True, but the text will have to be clear that a MC_CENTRIC device is a
device that can't be controlled by a V4L2-centric application.
Thanks,
Mauro
next prev parent reply other threads:[~2017-08-25 11:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 9:40 [PATCH 0/3] document types of hardware control for V4L2 Mauro Carvalho Chehab
2017-08-25 9:40 ` [PATCH 1/3] media: open.rst: document devnode-centric and mc-centric types Mauro Carvalho Chehab
2017-08-25 10:32 ` Hans Verkuil
2017-08-25 11:08 ` Sakari Ailus
2017-08-25 13:11 ` Laurent Pinchart
2017-08-25 13:38 ` Mauro Carvalho Chehab
2017-08-25 13:57 ` Laurent Pinchart
2017-08-25 14:02 ` Hans Verkuil
2017-08-25 9:40 ` [PATCH 2/3] media: videodev2: add a flag for vdev-centric devices Mauro Carvalho Chehab
2017-08-25 9:44 ` Hans Verkuil
2017-08-25 10:06 ` Mauro Carvalho Chehab
2017-08-25 10:13 ` Hans Verkuil
2017-08-25 10:35 ` Mauro Carvalho Chehab
2017-08-25 10:42 ` Hans Verkuil
2017-08-25 10:50 ` Mauro Carvalho Chehab
2017-08-25 10:56 ` Hans Verkuil
2017-08-25 11:15 ` Mauro Carvalho Chehab [this message]
2017-08-25 11:30 ` Mauro Carvalho Chehab
2017-08-25 11:35 ` Mauro Carvalho Chehab
2017-08-25 11:42 ` Hans Verkuil
2017-08-25 13:27 ` Laurent Pinchart
2017-08-25 9:40 ` [PATCH 3/3] media: add V4L2_CAP_VDEV_CENTERED flag on vdev-centric drivers 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=20170825081503.13e4df80@vento.lan \
--to=mchehab@s-opensource.com \
--cc=corbet@lwn.net \
--cc=hans.verkuil@cisco.com \
--cc=hansverk@cisco.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=mchehab@osg.samsung.com \
--cc=sakari.ailus@linux.intel.com \
/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).