On 09/11/2020 12:54, Daniel W. S. Almeida wrote: > 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? For virtual drivers it models the virtual hardware. Userspace doesn't know that it is actually all emulated, it just looks like real hardware. > > 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 Yes, it is separate. If CONFIG_MEDIA_CONTROLLER_DVB=y then an additional device node /dev/media0 is created. > > 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? I think that's because only a subset of DVB drivers support the media controller. > > >> 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 I'm not a DVB expert, but I was thinking of testing if it can discover channels, and perhaps just a test to stream data without checking if it is actually valid video. The problem is that I am not all that familiar with the DVB utilities so I don't know if anything can be automated. An alternative is to start adding dtv support to v4l2-compliance. That utility already has media controller support, but it needs a bit of work to comfortably integrate DTV support as well. I can help with that if you want to go in that direction. v4l2-compliance would need a bit of refactoring, but it is nice to have the tests there since that makes it easy to support hybrid devices with a single compliance utility. Regards, Hans
