Re: v4l2 api

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



>  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





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux