On Fri October 12 2012 00:41:37 Alain VOLMAT wrote:
> Hi Laurent,
>
> > -----Original Message-----
> > From: Laurent Pinchart [mailto:[email protected]]
> > Sent: vendredi 12 octobre 2012 00:22
> > To: Alain VOLMAT
> > Cc: Linux Media Mailing List ([email protected])
> > Subject: Re: Proposal for the addition of a binary V4L2 control type
> >
> > Hi Alain,
> >
> > On Thursday 11 October 2012 22:50:29 Alain VOLMAT wrote:
> > > Hi guys,
> > >
> > > In the context of supporting the control of our HDMI-TX via V4L2 in
> > > our SetTopBox, we are facing interface issue with V4L2 when trying to
> > > set some information from the application into the H/W.
> > >
> > > As an example, in the HDCP context, an application controlling the
> > > HDMI-TX have the possibility to inform the transmitter that it should
> > > fail authentication to some identified HDMI-RX because for example
> > > they might be known to be "bad" HDMI receiver that cannot be trusted.
> > > This is basically done by setting the list of key (BKSV) into the HDMI-TX
> > > H/W.
> > >
> > > Currently, V4L2 ext control can be of the following type:
> > >
> > > enum v4l2_ctrl_type {
> > > V4L2_CTRL_TYPE_INTEGER = 1,
> > > V4L2_CTRL_TYPE_BOOLEAN = 2,
> > > V4L2_CTRL_TYPE_MENU = 3,
> > > V4L2_CTRL_TYPE_BUTTON = 4,
> > > V4L2_CTRL_TYPE_INTEGER64 = 5,
> > > V4L2_CTRL_TYPE_CTRL_CLASS = 6,
> > > V4L2_CTRL_TYPE_STRING = 7,
> > > V4L2_CTRL_TYPE_BITMASK = 8,
> > > }
> > >
> > > There is nothing here than could efficiently be used to push this kind
> > > of long (several bytes long .. not fitting into an int64) key information.
> > > STRING exists but actually since they are supposed to be strings, the
> > > V4L2 core code (v4l2-ctrls.c) is using strlen to figure out the length
> > > of data to be copied and it thus cannot be used to push this kind of blob
> > > data.
> > >
> > > Would you consider the addition of a new v4l2_ctrl_type, for example
> > > called V4L2_CTRL_TYPE_BINARY or so, that basically would be pointer +
> > > length. That would be helpful to pass this kind of control from the
> > > application to the driver. (here I took the example of HDCP key blob
> > > but that isn't of course the only example we can find of course).
> >
> > If I remember correctly Hans Verkuil wasn't happy with the concept of
> > binary controls.
That's correct. Controls should be 1) fairly elementary types and 2) have clear
semantics. Binary blobs are neither.
> > While I'm
> > not totally against it, I agree with him that it could open the door to
> > abuses. There are valid use
> > cases though, both for binary "strings" (such as encryption keys) and
> > binary arrays (such as
> > gamma tables).
> > Completely random binary blobs are not a good idea though.
> >
> > So far we've worked around the absence of binary controls by using custom
> > ioctls (or even
> > standardizing new ioctls). It might or might not be a good solution for
> > your problem, depending
> > on your exact use cases.
>
> Ok, at least for the HDCP keys table we could for an ioctl if that's already
> the case in some other situations.
Look at the EDID ioctls in v4l2-subdev.h. The HDCP ioctls should be next to
them.
If I remember correctly you need a get ioctl to obtains the keys from a receiver
and a set ioctl to set the keys for a transmitter.
> I can however think about some cases where passing such binary controls is
> better than ioctl in case of it is necessary achieve several settings in an
> atomic way (which is I believe one of the merit of ext_control). Still in the
> field of HDMI-TX I can at least think about setting video post processing
> setting tables & mode change at the same time for example.
> If one setting is already available via a control and the other one has to be
> done via an ioctl, then it becomes hard to ensure that this is done in an
> atomic way back at the driver level.
>
> So, in short, for HDCP keys, there might not be a problem with ioctl but for
> other HDMI-TX settings, I'm afraid we will face problems.
>
> I am preparing some proposal for some new HDMI-TX controls (or ioctl ?) for
> things like SPD, AVMUTE, CONTENT_TYPE etc, I guess we could discuss about
> that problem again at that time.
A lot of the stuff that's in InfoFrames lends itself perfectly to controls.
They are both simple types and have clear semantics.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
