[Linux-kernel-mentees] On test-media script integration for vidtv

Daniel W. S. Almeida dwlsalmeida at gmail.com
Mon Nov 9 11:54:25 UTC 2020

Hi Hans & Mauro.

Well I now have some more time to work on vidtv so I'd like to start off 
with the test-media script integration as mentioned by Hans some time ago.

Let's recap:

> For regression testing of vidtv during the daily build it would be great if
> the contrib/test/test-media script can be enhanced to include vidtv.
> This is run during the daily build with a kernel that has lockdep and many
> other checks enabled, so it is very helpful to verify that no regressions
> happened.
> Note that this script relies on the /dev/mediaX devices to run the tests. I
> noticed that vidtv doesn't appear to create a /dev/mediaX device, even though
> CONFIG_MEDIA_CONTROLLER_DVB=y. This is definitely something that would be good
> to support in vidtv.
> Regards,
> Hans

So I have been looking at the documentation for a bit, i.e.

> https://www.kernel.org/doc/html/v4.14/media/uapi/mediactl/media-controller-intro.html

What I understood from that is that entities and interfaces under 
/dev/media/ are created to model actual hardware, but vidtv is a virtual 
driver. Can this be clarified?

Is this separate from the files created by the dvb core as part of the 
driver initialization?
e.g. (for a single adapter):


Btw I noticed some drivers call dvb_create_media_graph() as part of 
their initialization, e.g. au0828-dvb.c, em28xx-dvb.c, cx231xx-dvb.c, 
but some (most) do not, why is this?

> Daniel, if you look at the test-media script, then you'll see that it has
> separate sections for each virtual driver. It's probably best to look at
> the vim2m driver tests since that's the easiest.
> It loads the module, then it starts v4l2-compliance to test the API. This
> utility basically tries all V4L2 APIs and checks that the driver conforms to
> the spec.
> Note that you see options like '-m platform:vim2m' that selects which /dev/media
> device to use based on the name and v4l2-compliance (or v4l2-ctl with the -z option)
> then walks the topology of the media device and tests all interfaces it finds.
> Hence my question about media controller support in vidtv: this should be
> supported there as well since it allows you to write these test sequences without
> having to know which /dev/fooX device should be used.
> After the compliance test is run the script tests unbind/bind (always a nasty test)
> and checks for memory leaks (if enabled in the kernel).
> Much of this test sequence can be copied for vidtv, but you need something else for
> the compliance test. It would for now be enough to have some quick check with the
> existing dvb utils from v4l-utils to see that the basics work.
> IMHO I think a dtv-compliance utility along the lines of v4l2-compliance and
> cec-compliance should be created.
> I'm actually wondering whether the dtv compliance tests shouldn't be part of
> v4l2-compliance (which would have to be renamed to media-compliance in that case)
> since there are hybrid drivers supporting both in the same media topology.
> This would make compliance tests possible where analog/digital TV mode handling
> is tested (i.e. if analog TV is in use, then trying to use digital TV would return
> EBUSY and vice versa).
> It would require some work in v4l2-compliance.cpp to make this possible, but I
> can do that myself.
> Compliance tests have proven to be a great method of testing for regressions and
> testing drivers in general.
> Note that it takes a lot of time to create good compliance tests, but you just start
> with some simple tests and expand it over time.
> Regards,
> Hans

Well, I checked the test-media script and it seems to be easy to add 
support for vidtv there, as Hans said most of the sequence there can be 
copied from the other drivers. However..

 >It would for now be enough to have some quick check with the existing 
dvb utils from v4l-utils to see that the basics work.

Can we discuss this in further depth please? Maybe a few examples?

What I currently do is:

1. zap the stream & open it in dvbinspector, manually check for mistakes
2. manually check dmesg for errors
3. maybe play the stream using vlc or Kaffeine

-- thanks
-- Daniel

More information about the Linux-kernel-mentees mailing list