Hi Gerd, On Wed, 2002-10-16 at 12:54, Gerd Knorr wrote: > ALSA yes, not sure about OSS. OSS too, it's just that lots of drivers implement it in a broken way, due to which applications still need to support both read() and mmap() to work with both cases in case the other is broken in drivers. Ugh. But all OSS drivers implement both ways, as far as I know. > I like the idea to use exactly the same struct for TRY_FMT + S_FMT. > It helps to avoid stupid mistakes. Some application can do a TRY_FMT, > check the format it got back, and if it is happy with the result it can > simply pass the same struct to S_FMT and be done with it. No need to > copy the fields from one struct to another. And we can be sure that we > havn't forgotten something. For example the application can also return > which fields it will use if you pass in V4L2_FIELD_ANY ... Hmm okay, I think you've convinced me with the 'no need to copy fields' argument. Sounds reasonable, will just be some extra work for in the drivers (but we'll have to update them anyway). > The new approach allows to do some new things. One common approach to > sync tv overlay and monitor refresh is the following: > > (1) setup three buffers in offscreen memory. > (2) let the video source fill these tree buffers, one after another > and start over with the first one once the third is full. > (3) the graphics card switches the overlay to the freshest, completely > filled buffer during the vertical blank intervall. > > This avoids artefacts due to the video data being updated while the > gfx card reads them. You'll see those nicely if the camera moves. Interesting... This is what the v4l/Xv extension will do? I'll have to see how drivers would exactly implement this, but it does sound interesting... Not very easy, though. > The approach mentioned above _allows_ applications to do that using the > well-known v4l2 streaming API (i.e. we don't have to add a bunch of new > concepts and ioctls for that). It doesn't force applications into doing > that. Ok, I misunderstood that part. Thanks for explaining. > * Documentation: Where will the updated API docs appear on the web? > I'd like to have some up-to-date URL in the header file when > submitting stuff to Linus. Or should we also ship that with the > kernel maybe? Both, I guess... Anyway, Michael/Gerd, thanks for the work so far, it seems promising, I'll have a good critical look at the header file and send any remaining comments later on. Ronald
