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).
Regards,
Alain
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
