> > > I like this type field a lot! Can this be added to the cropping set/get > > > ioctl()s as well? > > > > Sounds reasonable, done. > > I assumed cropping dimensions apply to capture & overlay alike. A type > field allows two sets of cropping parameters in simultaneous > capture/overlay mode. Do you want that? If so, how are the semantics > when the driver supports only one set? If not, why else do we need a > type field? We have that issue even without the type field: With two active file descriptors, one being used for overlay, the other for capture, both trying to crop the image ... I like to have the type field there. It forces app authors to make clear what the application wants to do. It also might be useful information for the driver whenever the crop parameters are going to be used for overlay or capture. > > * for S_FBUF I'd like to pass a device instead of a physical address, > > but there seems to be no standard way yet to pass this info between > > kernel + userland ... > > Something like PCI bus, device number and function perhaps? The X server > knows that, no question. Other apps, hm. Yes, thats another part of the problem. v4l-conf would have to figure the PCI slot too. Getting the physical RAM address is possible using DGA, but as far I know there is also no way to ask the X-Server for the PCI ID of the gfx card. Same issue with framebuffer devices ... > > * struct tuner: add some type field here too? For radio/tv/...? What > > about tuning analog SAT tv? Should we add something for that? The > > digital stuff I'd leave to the well-established DVB API. > > What happened to the tuner/modulator union idea? Right now it would be overkill IMHO, both radio + tv just set a frequency. It might be worth to think about for SAT TV support as this one needs some more fields as far I know. But I don't know details here, someone else would have to suggest some useful API here. > > * 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? > > Kernel of course. But in the near future I think it's better somewhere > online, where we can easier correct mistakes, add clarifications, > examples, links etc. What about bytesex.org? Fine with me. I can give you ssh access to the box if you want (mail me your public key). Otherwise simply mail me a tarball, I'll put it online then. > > #define V4L2_MAJOR_VERSION 0 > > #define V4L2_MINOR_VERSION 20 > > 1.0 ? Hmm, I dropped the version altogether. Do we need it? If so, I'd prefeare to use the KERNEL_VERSION(a,b,c) macro. > > __u32 sample_format; /* V4L2_VBI_SF_* */ > > V4L2_PIX_FMT_* Done. 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
