Gerd Knorr wrote: > > Take some app which scans for TV stations. If a device has no tuner it > can just abort. Having the driver set this flag is one or two lines of > C code. Having the application check that by walking all inputs and > look for tuners needs much more code. One cannot change tuner properties without traversing the inputs to find it. So it's not much more code to write, only one for() loop less to execute. But you're right the flag is cheap, and the last thing I'm concerned about. > > I don't see a good reason why r/w and/or streaming must be mandatory. > > Is there? > > Applications can depend on r/w streaming support being available? I think a driver supporting both is more work than people will do just because the spec says so and some simple apps won't work. We can ignore reality or help apps to terminate cleanly. > We can also make this optional, but I'd create a single flag for > read/write then, another for streaming and maybe a third for > async I/O ... Sounds reasonable. Apropos, v4l/v4l2 lack the ability to check for a particular driver before using custom ioctls like BTTV_VBISIZE. It's just too easy to wipe out your hd when you don't know who's listening. (Well, not easy, but feasible.) What about a driver name and version field in v4l2_capabilites? Driver name is for the app and not modifyable, unlike the device name field for the user. Or is that info available from /proc? > > > 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 hope so. Have to check whenever the XFree86 Server provides the > infrastructure needed to handle the gfx card's side of this model. I would confirm that in the affirmative. Consider one buffer is read by the ramdac at vga refresh rate, another is written by video DMA at 50/60 Hz, the third is enqueued, number four unused. The X server already select()s on sockets, mouse and keyboard. The Xv driver can easily register as input device to sync with a v4l2 driver. When the DIX/OS layer calls back the driver enqueues the unused buffer and dequeues the previously filled buffer. Point is to always keep one buffer in the v4l2 empty queue for continuous capturing. It then writes the address of the filled buffer into a ramdac latch which is automatically transferred into the frame address register at vga vbi. We cannot recycle the previous buffer until that happens and the server cannot wait idle, so the ramdac effectively accesses two buffers at any time. At the next video irq the last recently displayed buffer is enqueued, if the switch didn't occur at this time the next one. When this cannot be detected five buffers are necessary. Of course all this should really work using field alternating mode and two pointers in the ramdac for top and bottom field. Then it may show F1/F2, F1/F2, F3/F2, F3/F2, F3/F4, ... The same api works for front-end (blitting) scalers, albeit without refresh sync. Again 3-4 buffers, on callback the Xv driver enqueues one, dequeues the previously filled buffer and starts a texture blit. It's more effort for the graphics processor, but this works on older cards without colorkeying or ramdac overlay. You can have any number of live video windows and the video is stored in on-screen memory (for alpha blending, screenshots etc). Done that in 98 (video input and output, at field granularity), worked quite well. Michael
