Gerd Knorr wrote: > > > how are the semantics when the driver supports only one set > > [of cropping/scaling parameters] > > 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 ... Oh-oh. Now it gets ugly. Basically I'd answer the driver may adjust one or both, capture and overlay parameters, when the cropping rectangle is modified. But another app causing the change is hardly acceptable. No cropping specific problem actually, simultaneous capture and overlay may impose all sorts of limitations. For example the same pixfmt or image size must be used. Once the operation started the parameters are locked, that's clear. Also for overlay the cropping rectangle is next to irrelevant, so once another capture app directly or indirectly requested a change the overlay app (identified by the type used) should have no business revoking that. Capturing and overlay size may be equally important. I.e. better to overlay exactly and capture what's visible, or capture images of particular size and display as best as possible? It will be strange if an app requests parameters and everything seems ok, but the subsequent streamon, preview on or r/w fails (not again -EINVAL, something unique) because the parameters have been invalidated in the meantime. However without an explicit locking mechanism I see no other way around. > 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. Ok. > > 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 ... What about /proc/bus/pci? Shouldn't the physical address (the address of the video memory aperture as seen by the CPU) appear there? OTOH when that works it's kinda silly the app must look up the bus id when it could just pass the physical address and the driver calls some pci helper function scanning the kernel structures reported there. > Hmm, I dropped the version altogether. Do we need it? If so, I'd > prefeare to use the KERNEL_VERSION(a,b,c) macro. That may be useful for drivers not in the kernel, to check if/how they can compile with the installed kernel. For apps it's pointless, AFAIK it was Linus himself suggesting apps shall use copies of kernel headers, not those in /usr/src/linux. It would be nice however if we could check for binary compatibility. The ioctls changed completely from v4l to v4l2, and since sizeof struct v4l2_capability changed one can also safely distinguish previous versions of VIDIOC_QUERYCAP. Right? Michael
