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):
/dev/adapter0/frontend0
/dev/adapter0/demux0
/dev/adapter0/dvr0
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
