Em 10-08-2011 05:41, Sylwester Nawrocki escreveu: >>>> Why not? I never saw an embedded hardware that allows physically changing >>>> the >>>> sensor. > > I understood Laurent's statement that you can have same ISP driver deployed on > multiple boards fitted with various sensors. Hence the multiple configurations > that cannot be known in advance,
True, but such kind of dependence should solved either at config time or at probe time. It doesn't make any sense to show that a hardware is present, when it is not. This applies to both V4L or MC APIs (and also to sysfs). >>>> If V4L2 API is not enough, implementing it on libv4l won't solve, as >>>> userspace >>>> apps will use V4L2 API for requresting it. >>> >>> There are two kind of applications: specialised and generic. The generic >>> ones may rely on restrictive policies put in place by a libv4l plugin >>> whereas the specialised applications need to access the device's features >>> directly to get the most out of it. >> >> A submitted upstream driver should be capable of working with the existing >> tools/userspace. >> >> Currently, there isn't such libv4l plugins (or, at least, I failed to see a >> merged plugin there for N9, S5P, etc). Let's not upstream new drivers or >> remove >> functionalities from already existing drivers based on something that has >> yet >> to be developed. >> >> After having it there properly working and tested independently, we may >> consider >> patches removing V4L2 interfaces that were obsoleted in favor of using the >> libv4l >> implementation, of course using the Kernel way of deprecating interfaces. But >> doing it before having it, doesn't make any sense. >> >> Let's not put the the cart before the horse. > > That's a good point. My long term plan was to deprecate and remove duplicated > ioctls > at the driver _once_ support for regular V4L2 interface on top of MC/subdev > API > is added at the v4l2 libraries. But this will happen after I create an > initial.. > *cough* openmax IL for the driver. Which is not what the Tigers like best.. Ok. > > -- > Regards, > Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
