archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <>
To: Mauro Carvalho Chehab <>,
	"Daniel W. S. Almeida" <>
Cc: "" <>,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver
Date: Mon, 14 Sep 2020 10:33:34 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20200912195702.58f71f8f@coco.lan>

On 12/09/2020 19:57, Mauro Carvalho Chehab wrote:
> Em Sat, 12 Sep 2020 11:49:01 -0300
> "Daniel W. S. Almeida" <> escreveu:
>> Hi Hans and Mauro & all
>>> Why the dvb_ prefix? All virtual drivers just start with 'vi'.
>>> And wouldn't it make more sense to call dvb_vidtv_bridge.ko just vidtv.ko?
>>> Just like the other virtual media drivers?  
>> I guess Mauro was the one to come up with the dvb_* prefix for the
>> kernel modules for the reasons he explicited up in this thread. 
>> As far as dvb_vidtv_bridge.ko and vidtv_bridge.c, I just wanted to be
>> verbose so that people would look at this and see that it is the code
>> for a bridge driver, since this is also supposed to be a template. 
>> Also because I had some trouble myself figuring out what was what when
>> first browsing through other dvb drivers. That said, I am 100% onboard
>> with renaming this to vidtv.ko or whatever seems more appropiate :)
> Let us think a little bit about that. 
>>> Yet, I agree with you that at least an alias is needed.
>>> earlier today, I wrote a patch with such purpose:  
>> If you all would like to just leave this at that ^ I am also ok with it.
>>> 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.  
>> Sure, I can do that if you'd like. Can you provide some tips on how to
>> get started? :)
> Hans can explain it better, but the hole idea is to have a set of
> userspace apps that will ensure that drivers will properly implement
> the DVB API.
> I suspect that, before that (or together with such tooling), we need
> to properly implement the frontend ioctl, validating the per delivery
> system parameters, as, right now, it just accepts anything from
> userspace. 

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.


Linux-kernel-mentees mailing list

  reply	other threads:[~2020-09-14  8:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21 12:58 [Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver Daniel W. S. Almeida
2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 1/4] media: vidtv: implement a tuner driver Daniel W. S. Almeida
2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 2/4] media: vidtv: implement a demodulator driver Daniel W. S. Almeida
2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 3/4] media: vidtv: add a bridge driver Daniel W. S. Almeida
2020-09-15 11:53   ` Geert Uytterhoeven
2020-09-15 13:26     ` Daniel W. S. Almeida
2020-09-15 13:35       ` Geert Uytterhoeven
2020-09-15 18:13         ` Daniel W. S. Almeida
2020-09-16  7:01         ` Mauro Carvalho Chehab
2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 4/4] media: Documentation: vidtv: Add ReST documentation for vidtv Daniel W. S. Almeida
2020-09-11  8:02 ` [Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver Mauro Carvalho Chehab
2020-09-11 12:18   ` Daniel W. S. Almeida
2020-09-11 13:10     ` Mauro Carvalho Chehab
2020-09-11 13:56       ` Mauro Carvalho Chehab
2020-09-12  2:54         ` Daniel W. S. Almeida
2020-09-12  7:38           ` Mauro Carvalho Chehab
2020-09-12  8:21 ` Hans Verkuil
2020-09-12  9:15   ` Mauro Carvalho Chehab
2020-09-12 14:49     ` Daniel W. S. Almeida
2020-09-12 17:57       ` Mauro Carvalho Chehab
2020-09-14  8:33         ` Hans Verkuil [this message]
2020-09-12  8:35 ` Hans Verkuil

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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).