On Saturday 11 October 2008 23:15:24 Andy Walls wrote:
> Hans,
>
> I'm fixing up the raw vbi checking logic in the cx18 driver and ran
> across a funny check in cx18-ioctl.c. See the FIXME in the function
> below:
>
> static int cx18_s_fmt_vbi_cap(struct file *file, void *fh,
> struct v4l2_format *fmt)
> {
> struct cx18_open_id *id = fh;
> struct cx18 *cx = id->cx;
> int ret;
>
> ret = v4l2_prio_check(&cx->prio, &id->prio);
> if (ret)
> return ret;
>
> /* FIXME - check stream type condition */
> if (id->type == CX18_ENC_STREAM_TYPE_VBI &&
> !cx18_raw_vbi(cx) && atomic_read(&cx->ana_capturing) > 0)
> return -EBUSY;
>
> cx->vbi.sliced_in->service_set = 0;
> cx->vbi.in.type = V4L2_BUF_TYPE_VBI_CAPTURE;
> cx18_av_cmd(cx, VIDIOC_S_FMT, fmt);
> return cx18_g_fmt_vbi_cap(file, fh, fmt);
> }
>
> It seems odd that if the ioctl() is called on a non-VBI stream fd, we
> can let the VIDIOC_S_FMT proceed even if there is an analog capture
> ongoing with sliced VBI.
>
> What am I missing?
Ah, you are right. The id->type check should be removed. I think it is a
left-over from the time that ivtv/cx18 both used the long ioctl
function instead of these smaller fmt functions. It might have made
sense then, but certainly not now.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
