From: "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>, hverkuil@xs4all.nl
Cc: linux-kernel-mentees@lists.linuxfoundation.org,
linux-media@vger.kernel.org
Subject: [Linux-kernel-mentees] On test-media script integration for vidtv
Date: Mon, 9 Nov 2020 08:54:25 -0300 [thread overview]
Message-ID: <838fdbcc-87b1-a40a-ebd3-59fce07f2d51@gmail.com> (raw)
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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next reply other threads:[~2020-11-09 11:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 11:54 Daniel W. S. Almeida [this message]
2020-11-09 14:21 ` [Linux-kernel-mentees] On test-media script integration for vidtv Hans Verkuil
2021-01-05 13:58 ` Daniel W. S. Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=838fdbcc-87b1-a40a-ebd3-59fce07f2d51@gmail.com \
--to=dwlsalmeida@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).