Hi Hans > -----Original Message----- > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > Sent: Friday, October 12, 2012 8:21 AM > To: Alain VOLMAT > Cc: Laurent Pinchart; Linux Media Mailing List (linux-media@xxxxxxxxxxxxxxx) > Subject: Re: Proposal for the addition of a binary V4L2 control type > > On Fri October 12 2012 00:41:37 Alain VOLMAT wrote: > > Hi Laurent, > > > > > -----Original Message----- > > > From: Laurent Pinchart [mailto:laurent.pinchart@xxxxxxxxxxxxxxxx] > > > Sent: vendredi 12 octobre 2012 00:22 > > > To: Alain VOLMAT > > > Cc: Linux Media Mailing List (linux-media@xxxxxxxxxxxxxxx) > > > 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. Well, yes, if keys goes up to the user space, yes those 2 ioctls will be needed. But another ioctl or control will also be needed to ENABLE & DiSABLE the HDCP / HDCP encryption I think. This doesn't always have to be enable so it should be necessary to allow triggering that. > > 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. Well at least SPD data that are (product name, vendor name, type) are a group of data. So if this is provided via controls (ext), then it will require to the application to set all 3 controls (string, string, integer) in a same s_ext_control in order to avoid getting only a partial SPD data update. Or we can rely on yet another ioctl (s_spd) to pass all 3 datas at the same time. > > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
