Re: [PATCHv3 01/20] media: add new types for DVB devnodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Sun, 11 Jan 2015 15:54:14 +0200
Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu:

> Hi Mauro,
> 
> On Thursday 08 January 2015 15:44:50 Mauro Carvalho Chehab wrote:
> > Em Thu, 08 Jan 2015 18:10:13 +0200 Laurent Pinchart escreveu:
> > > On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
> > >> Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
> > >>> Mauro Carvalho Chehab wrote:
> > >>>> Most of the DVB subdevs have already their own devnode.
> > >>>> 
> > >>>> Add support for them at the media controller API.
> > >>>> 
> > >>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxx>
> > >>>> 
> > >>>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > >>>> index 7902e800f019..707db275f92b 100644
> > >>>> --- a/include/uapi/linux/media.h
> > >>>> +++ b/include/uapi/linux/media.h
> > >>>> @@ -50,7 +50,14 @@ struct media_device_info {
> > >>>> 
> > >>>>   #define MEDIA_ENT_T_DEVNODE_V4L		(MEDIA_ENT_T_DEVNODE + 1)
> > >>>>   #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
> > >>>>   #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
> > >>>> 
> > >>>> -#define MEDIA_ENT_T_DEVNODE_DVB		(MEDIA_ENT_T_DEVNODE + 4)
> > >>>> +#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE + 4)
> > >>>> +#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE + 5)
> > >>>> +#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE + 6)
> > >>>> +#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE + 7)
> > >>>> +#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE + 8)
> > >>> 
> > >>> I'd create another type for the DVB sub-type devices, as there is for
> > >>> V4L2 sub-devices. I wonder what Laurent thinks.
> > >> 
> > >> I discussed this quickly with Laurent on IRC.
> > >> 
> > >> There are some concept differences between V4L2 and DVB.
> > >> 
> > >> At v4l2:
> > >> - the spec is one monolitic header (videodev2.h);
> > >> - one devnode is used to control everyhing (/dev/video?)
> > >> - there is one v4l core for all types of devices
> > >> 
> > >> At DVB:
> > >> - each different DVB API has its own header;
> > >> - each DVB device type has its own core (ok, they're
> > >>   linked into one module, but internally they're almost independent);
> > >> - each different DVB API has its own devnode.
> > >> 
> > >> So, using "SUBDEV" for DVB (or at least for the devnodes) don't
> > >> make much sense.
> > >> 
> > >> Ok, there are still some things at DVB side that could be mapped as
> > >> subdev. The clear example is the tuner. However, in this case, the
> > >> same tuner can be either V4L, DVB or both. So, we need to define just
> > >> one subdev type for the tuner.
> > >> 
> > >> Also, each DVB device can be identified via major/minor pairs.
> > >> 
> > >> I wrote already (and submitted upstream) the patches for media-ctl to
> > >> 
> > >> recognize them. They're also on my experimental v4l-utils tree:
> > >> 	http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-> >> 	utils.git/log/?h=dvb-media-ctl> 
> > >
> > > As I've mentioned in a previous discussion, the media_entity type field is
> > > too restrictive. Not only does this use case show that we need a type,
> > > sub-type and sub-sub-type, there are also entities that implement several
> > > distinct types. I thus believe we need a new ioctl is needed to expose
> > > detailed information about entities. This topic has been discussed
> > > numerous times in the past, it "just" requires someone to implement it.
> > > 
> > > I'm not opposed to a short-term solution like the one proposed here, but
> > > maybe we should instead decide it's time to implement the new ioctl
> > > instead.
> >
> > Ok, so let's stick with it for DVB. At DVB side, I don't see a need for
> > sub-sub-type, especially since DVB has no subdevs (except for the shared
> > tuner between DVB and V4L). Everything there are devnodes, with their
> > functionality strictly following the documentation, as the API is fully
> > handled inside the DVB core[1].
> 
> At the moment the MC API has a devnode type with a DVB devnode subtype. 
> Splitting DVB devnodes into different categories effectively create sub-
> subtypes. That's what bothers mode, the type field is becoming a ragbag.

As I explained before, and more detailed at:
	http://www.spinics.net/lists/linux-media/msg85229.html

DVB is actually 3 different APIs (demux, frontend and CA). Those APIs
are independent, and each have an independent devnode. The dvr is a
special case: it is a devnode that doesn't accept ioctl's. It is just
an output devnode, controlled vis the demux API.

The only thing in common to those 3 APIs is that they belong to the same
device type. But some may argue that, on an hybrid device, the input,
remote controller and even V4L2 are also sub-types.

In any case, they're all devnodes, so MEDIA_ENT_T_DEVNODE_foo fits well.

> 
> > Also, I don't want to mix adding DVB media controller support with the
> > addition of a new ioctl.
> 
> *If* we conclude that a new ioctl is needed to support DVB in a clean way, I 
> don't see why that new ioctl shouldn't be considered as a prerequisite.

I don't see the need of a new ioctl for DVB. DVB is even simpler than V4L2,
as it doesn't have subdevs (except for tuner).

> 
> > [1] For the non-deprecated DVB devnodes. DVB have 3 devnode types that
> > are deprecated because they implement functionality found elsewhere
> > (video, audio and OSD dvb APIs). Only one legacy driver implements it,
> > and there's no plan to ever add media controller or expand/accept
> > new drivers using those legacy APIs.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux