The V4L2 spec has some funny languague in the VIDIOC_S_FMT, and VIDIOC_TRY_FMT documentation and section 4.8.3 on setting or trying sliced VBI formats. For VIDIOC_TRY_FMT for sliced vbi, the ioctl() is only supposed to fail if the v4l2_format->type is for sliced vbi capture or sliced vbi output and it is not supported. Otherwise the ioctl() is to successfully return the sanitized v4l2_format->fmt.sliced.service_set and v4l2_format->fmt.sliced.service_lines, even if the sanitization returns them all as 0, implying no support for what was requested. I'm OK with all that so far. For the VIDIOC_S_FMT for sliced vbi, the driver is supposed to return -EBUSY if the operation can happen right now (that's fine), or -EINVAL if the passed in parameters are "ambiguous". What does ambiguous mean here? Specifically, does that include a VIDIOC_S_FMT where the v4l2_format->fmt.sliced.service_set and v4l2_format->fmt.sliced.service_lines all come back as zero when sanitized as with VIDIOC_TRY_FMT? I ask, becasue the cx18 driver, with VBI ioctl() code of ivtv origin, returns -EINVAL in this case, but that doesn't seem right to me. There's nothing ambiguous about a well formed request for a service set combination that isn't supported at all by the hardware. It's a valid request, as affirmed by VIDIOC_TRY_FMT, even if it is a useless request as far as VIDIOC_S_FMT and actually capturing VBI data is concerned. I suspect there might be some history or rationale I don't know about which would be fine. I'd just like to clean up the ambiguous "ambiguous" in the V4L2 spec in that case. Regards, Andy -- 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
