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 <redacted>
From: Sakari Ailus <sakari.ailus@linux.intel.com> Date: 2015-01-07 14:09:07
Hi Mauro,
Mauro Carvalho Chehab wrote:
quoted hunk
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 <redacted>
Em Wed, 07 Jan 2015 16:09:04 +0200
Sakari Ailus [off-list ref] escreveu:
Hi Mauro,
Mauro Carvalho Chehab wrote:
quoted
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 <redacted>
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
Regards,
Mauro
Hi Mauro,
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
quoted
Mauro Carvalho Chehab wrote:
quoted
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 <redacted>
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.
--
Regards,
Laurent Pinchart
Em Thu, 08 Jan 2015 18:10:13 +0200
Laurent Pinchart [off-list ref] escreveu:
Hi Mauro,
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
quoted
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
quoted
Mauro Carvalho Chehab wrote:
quoted
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 <redacted>
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].
Also, I don't want to mix adding DVB media controller support with the
addition of a new ioctl.
[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.
Regards,
Mauro
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:
quoted
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
quoted
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
quoted
Mauro Carvalho Chehab wrote:
quoted
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 <redacted>
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.
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.
[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.
Em Sun, 11 Jan 2015 15:54:14 +0200
Laurent Pinchart [off-list ref] escreveu:
Hi Mauro,
On Thursday 08 January 2015 15:44:50 Mauro Carvalho Chehab wrote:
quoted
Em Thu, 08 Jan 2015 18:10:13 +0200 Laurent Pinchart escreveu:
quoted
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
quoted
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
quoted
Mauro Carvalho Chehab wrote:
quoted
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 <redacted>
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.
quoted
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).
quoted
[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.