From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org, detlev.casanova@gmail.com
Subject: Re: [RFC PATCH 0/2] Allow inheritance of private controls
Date: Sun, 02 Feb 2014 10:45:24 +0100 [thread overview]
Message-ID: <14055698.TyElnNSLTS@avalon> (raw)
In-Reply-To: <1391166726-27026-1-git-send-email-hverkuil@xs4all.nl>
Hi Hans,
Thank you for the patches.
On Friday 31 January 2014 12:12:04 Hans Verkuil wrote:
> Devices with a simple video pipeline may want to inherit private controls
> of sub-devices and expose them to the video node instead of v4l-subdev
> nodes (which may be inhibit anyway by the driver).
>
> Add support for this.
>
> A typical real-life example of this is a PCI capture card with just a single
> video receiver sub-device. Creating v4l-subdev nodes for this is overkill
> since it is clear which control belongs to which subdev.
The is_private flag has been introduced to allow subdevs to disable control
inheritance. We're now adding a way for bridges to override that, which makes
me wonder whether private controls are really the best way to express this.
Shouldn't we think about what we're trying to achieve with controls and places
where they're exposed and then possibly rework the code accordingly ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-02-02 9:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 11:12 [RFC PATCH 0/2] Allow inheritance of private controls Hans Verkuil
2014-01-31 11:12 ` [RFC PATCH 1/2] v4l2-ctrls: add add_priv arg to v4l2_ctrl_add_handler Hans Verkuil
2014-01-31 11:12 ` [RFC PATCH 2/2] v4l2-device: add inherit_private_ctrls field Hans Verkuil
2014-02-02 9:45 ` Laurent Pinchart [this message]
2014-02-03 8:55 ` [RFC PATCH 0/2] Allow inheritance of private controls Hans Verkuil
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=14055698.TyElnNSLTS@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=detlev.casanova@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox