You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we are wrapping calls to G_CTRL into G_EXT_CTRLS in order to limit the number of ioctls we need to support.
This works most of the time, except when quering a 64-bit control: in this case G_CTRL is supposed to return -EINVAL because the value type of v4l2_ctrl is 32-bit and thus cannot hold the requested control's value (same for string and class controls). The following code in v4l2-compliance is what enforces this:
if (qctrl.type == V4L2_CTRL_TYPE_INTEGER64 ||
qctrl.type == V4L2_CTRL_TYPE_STRING ||
qctrl.type == V4L2_CTRL_TYPE_CTRL_CLASS) {
ret = doioctl(node, VIDIOC_G_CTRL, &ctrl);
if (ret != EINVAL &&
!((qctrl.flags & V4L2_CTRL_FLAG_WRITE_ONLY) && ret == EACCES))
So it seems like we have to forward the G_CTRL and S_CTRL ioctls to the host in order to handle this case.
The text was updated successfully, but these errors were encountered:
Right now we are wrapping calls to
G_CTRL
intoG_EXT_CTRLS
in order to limit the number of ioctls we need to support.This works most of the time, except when quering a 64-bit control: in this case
G_CTRL
is supposed to return-EINVAL
because thevalue
type ofv4l2_ctrl
is 32-bit and thus cannot hold the requested control's value (same for string and class controls). The following code inv4l2-compliance
is what enforces this:So it seems like we have to forward the
G_CTRL
andS_CTRL
ioctls to the host in order to handle this case.The text was updated successfully, but these errors were encountered: