Em Thu, 7 Jun 2018 16:47:50 +0900 Tomasz Figa <tf...@chromium.org> escreveu:
> On Thu, Jun 7, 2018 at 1:26 AM Mauro Carvalho Chehab > <mchehab+sams...@kernel.org> wrote: > > > > Em Wed, 6 Jun 2018 13:19:39 +0900 > > Tomasz Figa <tf...@chromium.org> escreveu: > > > > > On Mon, Jun 4, 2018 at 10:33 PM Mauro Carvalho Chehab > > > <mchehab+sams...@kernel.org> wrote: > [snip] > > > > 3.2 libv4l2 support for 3A algorithms > > > > ===================================== > > > > > > > > The 3A algorithm handing is highly dependent on the hardware. The > > > > idea here is to allow libv4l to have a set of 3A algorithms that > > > > will be specific to certain mc-based hardware. > > > > > > > > One requirement, if we want vendor stacks to use our solution, is that > > > > it should allow allow external closed-source algorithms to run as well. > > > > > > > > The 3A library API must be standardized, to allow the closed-source > > > > vendor implementation to be replaced by an open-source implementation > > > > should someone have the time and energy (and qualifications) to write > > > > one. > > > > > > > > Sandboxed execution of the 3A library must be possible as closed-source > > > > can't always be blindly trusted. This includes the ability to wrap the > > > > library in a daemon should the platform's multimedia stack wishes > > > > and to avoid any direct access to the kernel devices by the 3A library > > > > itself (all accesses should be marshaled by the camera stack). > > > > > > > > Please note that this daemon is *not* a camera daemon that would > > > > communicates with the V4L2 driver through a custom back channel. > > > > > > > > The decision to run the 3A library in a sandboxed process or to call > > > > it directly from the camera stack should be left to the camera stack > > > > and to the platform integrator, and should not be visible by the 3A > > > > library. > > > > > > > > The 3A library must be usable on major Linux-based camera stacks (the > > > > Android and Chrome OS camera HALs are certainly important targets, > > > > more can be added) unmodified, which will allow usage of the vendor > > > > binary provided for Chrome OS or Android on regular Linux systems. > > > > > > This is quite an interesting idea and it would be really useful if it > > > could be done. I'm kind of worried, though, about Android in > > > particular, since the execution environment in Android differs > > > significantly from a regular Linux distributions (including Chrome OS, > > > which is not so far from such), namely: > > > - different libc (bionic) and dynamic linker - I guess this could be > > > solved by static linking? > > > > Static link is one possible solution. IMHO, we should try to make it > > use just a C library (if possible) and be sure that it will also compile > > with bionic/ulibc in order to make it easier to be used by Android and > > other embedded distros. > > > > > - dedicated toolchains - perhaps not much of a problem if the per-arch > > > ABI is the same? > > > > Depending on library dependency, we could likely make it work with more > > than one toolchain. I guess acconfig works with Android, right? > > If so, it could auto-adjust to the different toolchains everywhere. > > That works for open source libraries obviously. I was thinking more > about the closed source 3A libraries coming from Android, since we > can't recompile them. Ah! It probably makes sense to place them on some sandboxed environment. If we're using that, it probably makes sense to have them running on a sort of daemon with a sockets-based API. If we're willing to do that, it doesn't really matter how the 3A was implemented. It can even be in Java. All it matters is to have a way to plug the library to it. A config file could provide such link, telling what 3A library should be used (and, eventually, what commands should be used to start/stop the daemon). Thanks, Mauro
