[PATCH] cafe_ccic: add support for VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS

Dan Williams dcbw at redhat.com
Sat Jul 7 10:17:06 EDT 2007


On Fri, 2007-07-06 at 16:30 -0600, Jonathan Corbet wrote:
> Dan Williams <dcbw at redhat.com> wrote:
> 
> > Newer gstreamer v4l2 plugins require these ioctls to determine supported
> > frame sizes and rates.  Unfortunately, the kernel v4l2 bits don't have
> > members in 'struct video_device' for these ioctls, so we have to
> > override the generic ioctl handler for these two functions.  They report
> > only VGA size @ 30fps as being supported for now.
> 
> Interesting, I didn't know about that.  I just sent a question off to
> Mauro (the V4L2 maintainer) on why those ioctls aren't wired up through
> video_ioctl2().  His answer, essentially, is "nobody was using them
> yet."

Well, gstreamer 0.10.6 now is using those, and in 2.6.22, apparently 4
different drivers have hooked up the FRAMESIZES, and one of those has
hooked up FRAMEINTERVALS (pwc, for example, but it doesn't even use the
video_ioctl2 hook).

The old method of determining largest framesize was complete crack and
broke with a lot of drivers, so I'm a great fan of having these explicit
commands :)  You used to pass in the basically INT_MAX and the driver
was supposed to clip that and return what it supported, but since v4l2
drivers are about where wireless+WEXT was 2 years ago, of course nobody
has consistent behavior even though v4l2 actually has a spec.

> I don't think this patch is destined for the mainline in its current
> form.  The right thing to do is to add callbacks for those commands and
> support them for all drivers through video_ioctl2().  Shouldn't be that

Yeah, that's obviously the right thing to do.  However, it's not in
2.6.22 yet, and we probably won't ship 2.6.23 in our first release, so
we may need to carry some patch like this in olpc-2.6 until we move to
2.6.23.  See below for more details :)

> hard of a thing to do.  Once that's done, the cafe_ccic driver should
> really just push those commands down to the sensor layer.  Then you
> could actually enumerate the real frame sizes and supported rates and
> you would not have to wire assumptions about the supported video formats
> into the controller driver.
> 
> I'm traveling (again, sigh) next week, but could probably hack something
> up the week after if you don't want to spend more time on this.

I'm not sure I'll have time... It's still unknown whether or not we need
to move to gstreamer-plugins-good-0.10.6 (which is where the rewritten
v4l2src is), because we still need to investigate whether it solves some
of the various problems we've seen.  If we do move to 0.10.6, we'll need
this patch or something like it.  If it doesn't, we stick with 0.10.5.

Thanks,
Dan





More information about the Devel mailing list