On Wed, Jul 4, 2018 at 5:55 PM Baruch Siach <baruch at tkos.co.il> wrote: > > Hi Tomasz, > > On Tue, Jul 03, 2018 at 11:29:03PM +0900, Tomasz Figa wrote: > > On Mon, Jul 2, 2018 at 11:57 PM Baruch Siach <baruch at tkos.co.il> wrote: > > > On Mon, Jul 02, 2018 at 04:30:52PM +0900, Tomasz Figa wrote: > > > > On Mon, Jul 2, 2018 at 4:25 PM Baruch Siach <baruch at tkos.co.il> wrote: > > > > > I'm trying to build the v4l plugin stand alone. But in the repo I only > > > > > see a Makefile.am file. I guess it integrates with the higher level > > > > > build system of CromiumOS. > > > > > > > > > > Do you have any idea how to build this v4l plugin code stand-alone? > > > > > > > > It's supposed to be built as a part of v4l-utils > > > > (http://git.linuxtv.org/v4l-utils.git), which includes libv4l. We > > > > build it with 1.6.0, but I guess newer versions may work too. > > > > > > > > For reference, here's our ebuild (for Gentoo portage) to build it: > > > > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/libv4lplugins/libv4lplugins-9999.ebuild > > > > > > The rockchip plugin code refers to the 'config_store' field in v4l2_buffer and > > > v4l2_ext_controls. This requires a special version of videodev2.h that is in > > > the chromeos-4.4 kernel (featuring commits 3b6d3bc13e572 and 86be552490a2a). > > > > > > The code of libv4l2 also requires patching since it refers to the 'reserved2' > > > field of v4l2_buffer since before version 1.6.0. > > > > > > I could not find these patches in the libv4l2 ebuild[1]. Where can I find > > > them? Is there some other version of libv4l2 that the rockchip plugin builds > > > against? > > > > The code is based on Chrome OS kernel headers [1], which are based on > > Chrome OS 4.4 kernel [2], which includes some downstream changes. > > 'config_store' comes from the V4L2 configuration store work in > > progress series by Hans Verkuil, which eventually evolved into what we > > know today as Request API (still not merged, though). The purpose of > > configuration stores was to bind specific V4L2 control values with > > particular buffers, since Rockchip encoder needs a number of low level > > encoding parameters for every frame [3]. > > > > Another caveat is that the encoder API we have implemented in that > > driver is just based on hardware registers (excluding the security > > sensitive registers, which the driver deals with directly). The plugin > > generates registers values and the driver just writes them to the > > hardware. This needs to be replaced with a proper stateless encoder > > API, based on Request API, which we're working on. > > So to get the rockchip-vpu driver working with current kernel I need to also > forward-port the embryonic Request API as well. I'll look into this. > > Are you aware of any other dependencies? I think V4L2 compound controls, but that should be already in upstream. I'll try to look up relevant Chromium kernel patches for you a bit later. > > The alternative for me is to back-port rkisp1 video capture driver to vendor > provided 4.4 kernel so I can use the MPP shim driver. I hope to not get there. > > The easiest option, of course, is to just wait for the Request API and the new > codec driver. I'm not sure I can afford to wait though. I think you could also try to remove the use of config stores and make the driver latch control values in QBUF(OUTPUT). You would also need to adjust the plugin code accordingly. Best regards, Tomasz
