On Wednesday 18 May 2011 15:03:13 Sylwester Nawrocki wrote: > On 05/18/2011 02:31 PM, Hans Verkuil wrote: > > On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote: > >> On 05/16/2011 09:21 AM, Laurent Pinchart wrote: > >> > On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: > >> >> On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: > >> >>> > >> >>> Thinking some more about it, does it make sense to set both crop and > >> >>> compose on a single video device node (not talking about mem-to-mem, > >> >>> where you use the type to multiplex input/output devices on the same > >> >>> node) ? If so, what would the use cases be ? > >> > >> I can't think of any, one either use crop or compose. > > > > I can: you crop in the video receiver and compose it into a larger > > buffer. > > > > Actually quite a desirable feature. > > Yes, right. Don't know why I imagined something different. > And we need it in Samsung capture capture interfaces as well. The H/W > is capable of cropping and composing with camera interface as a data source > similarly as it is done with memory buffers. The same result could be achieved by adding an offset to the buffer address and setting the bytesperline field accordingly, but that would only work with userptr buffers. As we're working on an API to share buffers between subsystems, I agree that composing into a larger buffer is desirable and shouldn't be implemented using offset/stride. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
