Hi Guennadi, On Wednesday 11 July 2012 18:10:05 Guennadi Liakhovetski wrote: Wow, that's an old mail :-) > On Fri, 6 Jul 2012, Laurent Pinchart wrote: > > On Friday 22 June 2012 18:40:08 Guennadi Liakhovetski wrote: > > > Add .get_selection() and .set_selection() soc-camera host driver > > > operations. Additionally check, that the user is not trying to change > > > the output sizes during a running capture. > > > > How will that interact with the crop operations ? The goal is to move away > > from crop operations to selection operations, so we need to establish > > clear rules. > > Nicely:-) My understanding is, that the V4L2 core now is doing a large > part (all of?) compatibility / conversion work? As you know, soc-camera is > a kind of a glue layer between the V4L2 core and host drivers with some > helper functionality for client drivers. All V4L2 API calls go via the > soc-camera core and most of them are passed, possibly after some > preprocessing, to host drivers. Same holds for cropping and selection > calls. They are passed on to host drivers. As long as drivers use the > cropping API, the soc-camera core has to support it. Only after all host > drivers have been ported over, the soc-camera core can abandon it too. I > don't see another way out, do you? My point was that it might be quite complex for soc-camera clients to implement both crop and selection operations. As the goal is to move both clients and hosts to selection operations, the soc-camera core could translate crop calls to selection calls if crop operations are not provided. Clients could then replace crop callbacks with selection callbacks without having to implement both as an interim solution. -- 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
