> Yup. And being able to use each of them would be a good thing, imho.
> Your point that you could do within alternate buffers is valid, it's
> just a personal preference of me to keep the fields sequential.
Have V4L2_FIELD_SEQ_TB + V4L2_FIELD_SEQ_BT now, ok?
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?
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
