On Sat, May 19, 2018 at 12:15 AM Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > Le vendredi 18 mai 2018 à 15:38 +0300, Laurent Pinchart a écrit : > > > Before libv4l, media support for a given device were limited to a few > > > apps that knew how to decode the format. There were even cases were a > > > proprietary app were required, as no open source decoders were available. > > > > > > From my PoV, the biggest gain with libv4l is that the same group of > > > maintainers can ensure that the entire solution (Kernel driver and > > > low level userspace support) will provide everything required for an > > > open source app to work with it. > > > > > > I'm not sure how we would keep enforcing it if the pipeline setting > > > and control propagation logic for an specific hardware will be > > > delegated to PipeWire. It seems easier to keep doing it on a libv4l > > > (version 2) and let PipeWire to use it. > > > > I believe we need to first study pipewire in more details. I have no personal > > opinion yet as I haven't had time to investigate it. That being said, I don't > > think that libv4l with closed-source plugins would be much better than a > > closed-source pipewire plugin. What main concern once we provide a userspace > > camera stack API is that vendors might implement that API in a closed-source > > component that calls to a kernel driver implementing a custom API, with all > > knowledge about the camera located in the closed-source component. I'm not > > sure how to prevent that, my best proposal would be to make V4L2 so useful > > that vendors wouldn't even think about a different solution (possibly coupled > > by the pressure put by platform vendors such as Google who mandate upstream > > kernel drivers for Chrome OS, but that's still limited as even when it comes > > to Google there's no such pressure on the Android side). > If there is proprietary plugins, then I don't think it will make any > difference were this is implemented. The difference is the feature set > we expose. 3A is per device, but multiple streams, with per request > controls is also possible. PipeWire gives central place to manage this, > while giving multiple process access to the camera streams. I think in > the end, what fits better would be something like or the Android Camera > HAL2. But we could encourage OSS by maintaining a base implementation > that covers all the V4L2 aspect, leaving only the 3A aspect of the work > to be done. Maybe we need to come up with an abstraction that does not > prevent multi-streams, but only requires 3A per vendors (saying per > vendors, as some of this could be Open Source by third parties). > just thinking out loud now ;-P > Nicolas > p.s. Do we have the Intel / IPU3 folks in in the loop ? This is likely > the most pressing HW as it's shipping on many laptops now. Yes, I added Jerry, Raj and Sakari to the first post and also this one. Best regards, Tomasz
