Gerd Knorr wrote:
>I've also dropped min/maxsize from v4l2_capabilities. It doesn't really
>belong there as the size might depend on serveral other factors (tv
>norm, ...). New struct + ioctl for image size negotiation:
>
>struct v4l2_check_size {
> enum v4l2_buf_type type; /* buffer type */
> int width;
> int heigth;
>};
>
>input: size the application want to use
>output: closest size the hardware can do for the given buffer type
>
>Most useful for overlay. For capture it is somewhat redundant because
>S_FMT also adjusts the values to the closest values supported by the
>hardware.
>
>Comments?
>
>
I like this. Much better than using S_FMT to negotiate sizes, since that
causes the hardware to change sizes (which can take a second or two with
some devices).
There's one thing that confuses me though... if the idea here is that
available sizes may depend on factors such as pixel format (which is the
case with some USB cams), how does the driver know what format the app
calling VIDIOC_CHECK_SIZE wants? There are width and height fields in
v4l2_pix_format, which kind of nullifies the value of VIDIOC_CHECK_SIZE
in that situation.
Would it be possible to remove width/height from v4l2_pix_format? One
thing about V4L1 that always bothered me was that different structs
contained some of the same fields (eg. video_mmap.format and
video_picture.palette). I had to add extra checks to VIDIOCSPICT in my
driver, so that setting brightness wouldn't reset the format registers
every time.
--
Mark McClelland
[EMAIL PROTECTED]
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
