> 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
