> 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. Is this a real issue? At least for the cards/chipsets doing overlay by PCI-PCI transfers there is no major difference between overlay and capture. So the crop issue is nothing really new, bttv and saa7134 already have to deal with different parameters for capture and/or overlay set by different applications. bttv basically does that by reprogramming the chip in the IRQ handler just before the frame gets captured, not when the application calls S_FMT. I have to recheck the specs, but IIRC the crop thing can be handled this way too. Don't know that much about other hardware (usb cams?) through ... > > 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? Not sure how portable that would be. It is easy on ix86 because physical address == bus address. > 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. Sounds reasonable to have some kernel helper function to figure the PCI device for a given physical address. > 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? Yes. 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
