> 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).
Good point, didn't know that changing formats might be _that_ expencive.
> 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?
Add pixelformat to struct v4l2_check_size?
> 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?
How do you set the image size then? v4l2_check_size just checks what
the hardware could do, it doesn't actually change the driver settings
...
> 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.
Yes. video_mmap was more or less a quick hack ...
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
