Gerd Knorr wrote: > > > 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 think that's a bad idea. See again, Ronald Bultje confirmed (if I understood correctly) he wants the _older_ field first, not top or bottom. So we would get one sequential-top-first (field order like interlaced, but lines not interleaved), the other sequential-oldest-first. The next person asks for two more interlaced, the missing two sequential or new alternating orders. IMHO we should just use two r/w-able flags for spatial and temporal order or something equivalent. That's most flexible, should be easy to understand and adds little more work compared to a fixed order: Assumed the driver behaves as first proposed, it only has to toggle the temporal order flag depending on the video standard. If the hardware doesn't permit the defaults, drivers can flag anything. When apps like lavrec can't use two pointers and adapt (or store the intended order in a file a la MPEG-2 or Quicktime), well, better luck next time. Finally drivers could adjust to the requested order. That needs to be specified in more detail, for example what happens when the flags cannot combine as requested, or do the flags reset at open(). In the meantime we can consider the flags r/o for apps. Apps could ignore the field order, but a well written one should at least check top/bottom. > I've also dropped min/maxsize from v4l2_capabilities. Fine. But something else, in the last version of your videodev.h it seems you dropped all capab flags. A brief summary: * TUNER is redundant because an app can just enumerate inputs to learn the hw can tune, and more (how many tuners, name, supported video standards, audio decoding, frequency range etc). * MONOCHROME is just another way to say the driver supports only V4L2_PIX_FMT_GREY. We can check that quite easily with VIDIOC_ENUM_PIXFMT. Although when the app can't even name a format, it can't probably handle the format. So why should it enumerate to build a menu or request that format later. * DATA_SERVICE became redundant with the removal of the vbi device type. * SELECT was removed because we agreed it's so important we can't afford to keep it optional. * PREVIEW (OVERLAY) - You said it's useful, what changed your mind? * READ/WRITE/STREAMING - Actually I thought this was never in question (unlike optional ioctls just returning -EINVAL). I always liked to enable the appropriate i/o routines without much ado. What's the alternative? Any other arguments pro/con I overlooked? Let's not throw out the baby with the bathwater. Michael
