Hi Gerd & Michael,
On Wed, 2002-10-16 at 09:44, Gerd Knorr wrote:
> Michael H. Schimek wrote:
> > 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.
> I understood it exactly the other way around: first field is always
> the temporal first. Ronald?
I *do* want to know whether it's topfirst or bottomfirst. (i.e., the
spatial top/bottom is first in time and thus sequentially first in the
JPEG buffer). The first field in this buffer is always the one which was
first in time, that's correct. The field that's first in time can
actually be set on demand - there *is* no first field for the zr36060
chip. The first field is just the field that you give a number=0;. so
what we want to set is whether we want to use a top field or a bottom
field as first capture field in the sequential buffer.
The above solution would work fine. Michael's suggestion to add two r/w
flags for temp/spatial order sounds fine too. Both would work.
> read/write/streaming not being optional (but mandatory like select
> support)?
Sounds fine, I think... Isn't that the case for audio cards as well?
(both write/read and mmap must be supported).
On Tue, 2002-10-15 at 11:18, Gerd Knorr wrote:
> 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
I like this type field a lot! Can this be added to the cropping set/get
ioctl()s as well?
On Wed, 2002-10-16 at 10:37, Gerd Knorr wrote:
> > VIDIOC_G_FMT, VIDIOC_S_FMT - We add v4l2_window, so these are the video
> > or raw vbi capture, output or video overlay parameters.
> That would also obsolete VIDIOC_G_WIN + VIDIOC_S_WIN.
I don't think I like that. They've got nothing to do with each other
from a userspace point of view, so keep them separate please. See below.
> > VIDIOC_TRY_FMT - Like VIDIOC_S_FMT, but does not change driver state.
> Good idea, better than my approach.
Hmm...
I think it's okay to make them behave the same, but S_FMT is really much
more complex than TRY_FMT. TRY_FMT should be kept simple. width, height,
buffer-type and format, that's really all you need. Would work for both
overlay and capture.
> Hmm. Maybe we should continue to go the way with making overlay not
> being that special any more. We could use v4l2_buffer to setup multiple
> buffers within the offscreen area:
For the driver, this may actually sound reasonable. From a userspace
(application) point of view, I don't see much reason to do that. I mean,
why would you? I don't see why it would make an application developer's
life easier.
> - V4L2_MEMORY_MMAP is the "classic" mmaping (offset+length returned
> by the QUERYBUF and passed to mmap())
> - V4L2_MEMORY_USERPTR allows applications to pass in pointers to
> random userspace memory (userptr+length).
> - V4L2_MEMORY_OVERLAY allows the applications to specify some piece
> of memory within the range configured by S_FBUF (with offset being
> relative to v4l2_framebuffer->base)
>
> Then the applications can either use the classic way
> "VIDIOC_OVERLAY(on/off)" or STREAMON / QBUF / DQBUF / STREAMOFF.
I think I prefer the older approach of video window and all that. Why?
Because it looks more natural from the application programmer's point of
view.You set a buffer where the framebuffer is located, you set the
window parameters + clips (which can be taken literally from X), just as
X would do internally, and you display it (OVERLAY(on)). That's so
natural... This is how it's *supposed* to be, imho.
Now, for overlay to be enabled in the new approach, I need to think
about buffers. But what do buffers (from a user point of view) have to
do with overlay? Overlay is just frame->graphicscard. I think the older
approach is just simpler and more natural.
for a driver developer's point of view, I don't think they'd be that
different anyway.
For all changes that we make, we actually have to think: what difference
would it make? We can change things all along, but we'd better keep
things simple too, where possible.
Btw, Gerd, can you send a newest version of videodev2.h? I'm curious how
it looks currently.
Ronald
