On 08/07/2020 05:59, Sergey Senozhatsky wrote: > On (20/07/07 15:41), Dave Stevenson wrote: >>> v4l2-compliance tests are in sync with our master and it expects that >>> that kernel is used. >> >> Thanks, I'd never noted that restriction. All previous times I'd used >> v4l2-compliance against any kernel it had performed as expected. This >> is the first change that causes a major failure of tests due to an >> older kernel. > > It depends on Linux UAPI headers, so the restriction is sort of mandated, > but probably not widely recognized the by the distributions, looking at > arch, for instance: > https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/v4l-utils > > Adding a Linux version check code can be a bit intrusive. There has been > a whole bunch of changes all over the place, for instance: > > --- > > +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp > @@ -381,8 +381,6 @@ int buffer::check(unsigned type, unsigned memory, unsigned index, > if (g_flags() & V4L2_BUF_FLAG_BFRAME) > frame_types++; > fail_on_test(frame_types > 1); > - fail_on_test(g_flags() & (V4L2_BUF_FLAG_NO_CACHE_INVALIDATE | > - V4L2_BUF_FLAG_NO_CACHE_CLEAN)); > --- > > So running newer v4l-compliance against the older kernel or older > v4l-compliance against the newer kernel may trigger various failures. It shouldn't. It's (I believe) just the check that those two flags are cleared if cache hints are not supported that should be under a version check. Regards, Hans
