On Sat, 10 Jan 2009, Trent Piepho wrote: > On Sat, 10 Jan 2009, Marton Balint wrote: > > Cx88_set_tvnorm sets the size of the video to fixed 320x240. This is ugly at > > least, but also can cause problems, if it happens during an active video > > transfer. With this patch, cx88_set_scale will save the last requested video > > size, and cx88_set_tvnorm will scale the video to this size. > > > > diff -r 985ecd81d993 -r 571b3176dc82 linux/drivers/media/video/cx88/cx88.h > > @@ -352,6 +352,9 @@ > > u32 input; > > u32 astat; > > u32 use_nicam; > > + unsigned int last_width; > > + unsigned int last_height; > > + enum v4l2_field last_field; > > Instead of adding these extra fields to the core, maybe it would be better > to just add w/h/field as arguments to set_tvnorm? I have a patch to do > this, but there are still problems. I think you're right, it's probably better that way. > Changing norms during capture has more problems. I'm not sure if v4l2 even > allows it. Even if allowed, I don't think the cx88 driver should try to > support it. What the other drivers do? > So I think the best thing would be to have S_STD return -EBUSY if there is > an ongoing capture. Maybe even have v4l2-dev take care of that if > possible. It sounds reasonable. As a special case, changing the norm to the current norm should be allowed, or not? Mplayer will print out error messages, if it's not allowed. Regards, Marton. -- 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
