Re: [GnomeMeeting-list] IBM Ultraport II Cam and gnomemeeting 0.85.1,RH 7.3, kernel 2.4.18-3

[Bill Dirks <bdirks pacbell net>]

The way V4L2 works, if an application requests an image format that the
driver cannot support, the driver should choose the closest format, and
change the v4l2_format structure to match. The application must check
the format structure after the call to get the granted dimensions.

The following is quoted from the V4L2 spec:
http://www.thedirks.org/v4l2/v4l2cap.htm

  Devices will not be able to support every combination of width
  and height. Upon a VIDIOC_S_FMT call, the driver will find the
  width and height compatible with the hardware which are as close
  as possible to the requested width and height without going over
  in either dimension. The driver will modify the structure to
  indicate the granted dimensions, and the resulting size of the
  image. Applications must make sure they are suitable. It is not
  considered an error when the dimensions need to be adjusted
  this way, and the ioctl() call will still return 0 in this case.
  The driver will also fill in the depth field appropriately for
  the selected pixel format.

V4L2 has always been spec'ed this way. 

Just peek at the v4l2_format structure again after the call, or do a
VIDIOC_G_FMT, to see the format you got.

This is a feature not a bug. Really. This way, if the application's
ideal format is not supported the driver will tell the app what its
closest supported format is. Otherwise the app would either have to
start guessing blindly through the whole 'format space', or fail. The
app can still fail if it really needs the exact format orginally
requested.

You've got an app bug, not a driver bug. If gnomemeeting can already to
padding, then it should be and easy fix.

Bill.

PS. Some v4l drivers may also work like this. It's good policy to read
the format back from the driver so you know that you know what the
driver state is.


Kurt Stephens wrote:
> 
> Ok, now I understand: gnomemeeting is asking for 176x144 from the driver
> , the driver is returning "OK" and not giving back 176x144 frames.  That
> is definitely a bug.
> 
> Thanks All,
> Kurt Stephens
> 
> Damien Sandras wrote:
> > On Mon, Jul 01, 2002 at 04:50:33PM -0500, Kurt Stephens wrote:
> >
> >>Isn't the driver returning the frames in the resolution as supported by
> >> the camera?  Or is the driver misreporting the dimensions of the
> >>frames from the ioctl() call?  Not supporting an application-specific
> >
> >
> > I don't know the behavior of the driver...
> >
> >
> >>(H.261) format does not necessarly make the driver buggy, unless that is
> >
> >
> > It has never been said that H.261 was an application specific format. H.261
> > is a codec. What I said is that, apparently, the driver didn't support
> > the QCIF size (176x144), which is not application-specific. Not supporting
> > it is not a bug, but apparently, it doesn't report any error when you
> > request that unsupported size, but instead gives a broken image.
> >
> >
> >>part of the V4L specification (i.e. a set of lowest common denominator
> >>formats must be supported for a V4L device).
> >>
> >>Making the application handle more device formats makes the application
> >>work with more drivers.  If I add scaling or padding code to
> >>gnomemeeting would it allow it to use more devices.  If I add scaling or
> >>padding code to ultracam.c, it only adds functionality to that device.
> >>Or does V4L2 handle this issue?
> >>
> >
> >
> > You misunderstood the problem, please read above and the preceding mail.
> > The problem is not with scaling or padding. GnomeMeeting already does
> > padding. The problem with the driver is that it doesn't support (apparently)
> > the QCIF size, but instead of reporting an error when an user program tries
> > to use that size, it doesn't report any error, but sends a broken image.
> >
> >
> >
> >>BTW: gcqcam-0.9 does not work with this driver either; I wonder if it
> >>makes the same assumptions about frame dimensions?  It opens the device
> >
> >
> > GnomeMeeting only assumes that if it ask for 176x144, and if the driver
> > reports it is ok, then it can use it.
> >
> >
> >>but does not seem to honor the format that the device supports and/or
> >>reports; I get the same type of bogus display.
> >>
> >>I'm trying to figure out where my effort is best directed.
> >>
> >
> >
> >
> > Damien