`VIDIOC_G_CTRL` cannot always be translated to `VIDIOC_G_EXT_CTRLS`

[Gnurou]

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.

[adelva1984]

I noticed https://lore.kernel.org/all/20250223-queryctrl-v3-0-4292911cab6b@chromium.org/ implemented a translator for these ioctls around query_ext, removing so fixing this seems like it might be a bit more complicated because we need to handle host or guest with or without the ioctls.

[Gnurou]

Yeah I also noticed that the non-ext ioctl handlers have disappeared completely, so I am not sure how to handle this without them. It's a pretty corner-case issue though.