Re: [RFC PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
Hi, On 07/04/2012 10:35 AM, Hans Verkuil wrote: snip snip Can we have a (hopefully short) irc discussion today? I'd really like to get this API finalized. +1, I'm available the entire day (CET office hours + evening if needed that is) snip snip So my current proposal is: use a bitfield in v4l2_frequency_band to describe possible (de)modulators and add compat code to the v4l2-ioctl.c to automatically create a vidioc_enum_freq_bands op if no such op was supplied, using the data from g_tuner or g_modulator and which device node was used to fill in the fields. +1 Regards, The other Hans :) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
Em 03-07-2012 04:19, Hans Verkuil escreveu:
On Mon 2 July 2012 19:42:33 Mauro Carvalho Chehab wrote:
Em 02-07-2012 11:15, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..d54ec6e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS 0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -2066,19 +2067,30 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u8name[32];
As we've discussed, band name can be inferred from the frequency.
Also, there are more than one name for the same band (it could be
named based on the wavelength or frequency - also, some bands or
band segments may have special names, like Tropical Wave).
Let's userspace just call it whatever it wants. So, I'll just
drop it.
That will lead to chaos IMHO: one application will call it one thing,
the other something else. Since the frequency band boundaries will
generally be slightly different between different products it is even
not so easy to map a frequency to a particular name. Not to mention
the simple fact that most apps will only ever see FM since the number of
products that support other bands is very, very small.
Sure, an application can just print the frequency range and use that
as the name, but how many end-users would know how to interpret that as
FM or AM MW, etc.? Very few indeed.
AM or FM can be retrieved from a modulation field. The band range is:
1) Country-dependent, e. g. they're defined by the regulator's
agency on each Country and standardized on ITU-R;
2) Per-country regulatory restrictions may apply, as it may be
illegal or it may be required an special license to operate outside the
public services range. Some of the supported devices for can be used
at the amateur radio range
3) requires locale support. For example, in Brazil:
short wave is OC
medium wave is OM
part of the OC band is called Tropical wave
...
Devices with dual TV/FM tuners allows a band that it is larger than SW+MW+LW.
How would you call such band?
What I'm saying is that an application that would properly implement radio
support will need to have a per-Country regulatory data, in order to name
a band, using the Country's denomination for that band.
It is not a Kernel's task to keep such database. It may be added on a library,
through.
On the other hand, the modulation is independent on the band, and
ITU-R and regulator agencies may allow more than one modulation type
and usage for the same frequency (like primary and secondary usage).
But the actual tuner/demod in question will support only one modulation
type per frequency range. It's not something you can change in our API. So
what's the use of such a modulation type? What would an application do with
it? I want to avoid adding a field for which there is no practical use.
Devices like bttv and cx88 with a TV/FM tuner allow at least 2 modulation types:
FM and SDR (Software Delivered Radio), as the internal RISC processor can
deliver
the IF samples though the DMA engine, allowing demodulation in userspace.
This API is used to show a combobox or similar to the end-user allowing
him/her
to select a frequency band that the radio application will use. So you need
human-readable names for the frequency bands that are understandable for
your average human being. Frequency ranges or talk about ITU standards are
NOT suitable for that.
It is not a Kernel's task to present a combobox. Also, converting the radio
band names into a combobox will require converting the band names into locale
data, with is more complex, less portable than to compare the band ranges with
the ITU-R tables.
That's said, let's suppose an application that would allow to
Re: [RFC PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
On Tue July 3 2012 18:01:51 Mauro Carvalho Chehab wrote:
Em 03-07-2012 04:19, Hans Verkuil escreveu:
On Mon 2 July 2012 19:42:33 Mauro Carvalho Chehab wrote:
Em 02-07-2012 11:15, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..d54ec6e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2066,19 +2067,30 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG20x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u8name[32];
As we've discussed, band name can be inferred from the frequency.
Also, there are more than one name for the same band (it could be
named based on the wavelength or frequency - also, some bands or
band segments may have special names, like Tropical Wave).
Let's userspace just call it whatever it wants. So, I'll just
drop it.
That will lead to chaos IMHO: one application will call it one thing,
the other something else. Since the frequency band boundaries will
generally be slightly different between different products it is even
not so easy to map a frequency to a particular name. Not to mention
the simple fact that most apps will only ever see FM since the number of
products that support other bands is very, very small.
Sure, an application can just print the frequency range and use that
as the name, but how many end-users would know how to interpret that as
FM or AM MW, etc.? Very few indeed.
AM or FM can be retrieved from a modulation field. The band range is:
1) Country-dependent, e. g. they're defined by the regulator's
agency on each Country and standardized on ITU-R;
2) Per-country regulatory restrictions may apply, as it may be
illegal or it may be required an special license to operate outside the
public services range. Some of the supported devices for can be used
at the amateur radio range
3) requires locale support. For example, in Brazil:
short wave is OC
medium wave is OM
part of the OC band is called Tropical wave
...
Devices with dual TV/FM tuners allows a band that it is larger than SW+MW+LW.
How would you call such band?
What I'm saying is that an application that would properly implement radio
support will need to have a per-Country regulatory data, in order to name
a band, using the Country's denomination for that band.
It is not a Kernel's task to keep such database. It may be added on a library,
through.
On the other hand, the modulation is independent on the band, and
ITU-R and regulator agencies may allow more than one modulation type
and usage for the same frequency (like primary and secondary usage).
But the actual tuner/demod in question will support only one modulation
type per frequency range. It's not something you can change in our API. So
what's the use of such a modulation type? What would an application do with
it? I want to avoid adding a field for which there is no practical use.
Devices like bttv and cx88 with a TV/FM tuner allow at least 2 modulation
types:
FM and SDR (Software Delivered Radio), as the internal RISC processor can
deliver
the IF samples though the DMA engine, allowing demodulation in userspace.
This API is used to show a combobox or similar to the end-user allowing
him/her
to select a frequency band that the radio application will use. So you need
human-readable names for the frequency bands that are understandable for
your average human being. Frequency ranges or talk about ITU standards are
NOT suitable for that.
It is not a Kernel's task to present a combobox. Also, converting the radio
band names into a combobox will require converting the band names into locale
data, with is more complex, less portable
Re: [RFC PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
Em 03-07-2012 13:47, Hans Verkuil escreveu:
On Tue July 3 2012 18:01:51 Mauro Carvalho Chehab wrote:
Em 03-07-2012 04:19, Hans Verkuil escreveu:
On Mon 2 July 2012 19:42:33 Mauro Carvalho Chehab wrote:
Em 02-07-2012 11:15, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..d54ec6e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -2066,19 +2067,30 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u8name[32];
As we've discussed, band name can be inferred from the frequency.
Also, there are more than one name for the same band (it could be
named based on the wavelength or frequency - also, some bands or
band segments may have special names, like Tropical Wave).
Let's userspace just call it whatever it wants. So, I'll just
drop it.
That will lead to chaos IMHO: one application will call it one thing,
the other something else. Since the frequency band boundaries will
generally be slightly different between different products it is even
not so easy to map a frequency to a particular name. Not to mention
the simple fact that most apps will only ever see FM since the number of
products that support other bands is very, very small.
Sure, an application can just print the frequency range and use that
as the name, but how many end-users would know how to interpret that as
FM or AM MW, etc.? Very few indeed.
AM or FM can be retrieved from a modulation field. The band range is:
1) Country-dependent, e. g. they're defined by the regulator's
agency on each Country and standardized on ITU-R;
2) Per-country regulatory restrictions may apply, as it may be
illegal or it may be required an special license to operate outside the
public services range. Some of the supported devices for can be used
at the amateur radio range
3) requires locale support. For example, in Brazil:
short wave is OC
medium wave is OM
part of the OC band is called Tropical wave
...
Devices with dual TV/FM tuners allows a band that it is larger than SW+MW+LW.
How would you call such band?
What I'm saying is that an application that would properly implement radio
support will need to have a per-Country regulatory data, in order to name
a band, using the Country's denomination for that band.
It is not a Kernel's task to keep such database. It may be added on a
library,
through.
On the other hand, the modulation is independent on the band, and
ITU-R and regulator agencies may allow more than one modulation type
and usage for the same frequency (like primary and secondary usage).
But the actual tuner/demod in question will support only one modulation
type per frequency range. It's not something you can change in our API. So
what's the use of such a modulation type? What would an application do with
it? I want to avoid adding a field for which there is no practical use.
Devices like bttv and cx88 with a TV/FM tuner allow at least 2 modulation
types:
FM and SDR (Software Delivered Radio), as the internal RISC processor can
deliver
the IF samples though the DMA engine, allowing demodulation in userspace.
This API is used to show a combobox or similar to the end-user allowing
him/her
to select a frequency band that the radio application will use. So you need
human-readable names for the frequency bands that are understandable for
your average human being. Frequency ranges or talk about ITU standards are
NOT suitable for that.
It is not a Kernel's task to present a combobox. Also, converting the radio
band names into a combobox will require converting the band names into locale
data, with is more complex, less portable than to compare the band ranges
with
the
Re: [RFC PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
Em 02-07-2012 11:15, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..d54ec6e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -2066,19 +2067,30 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u8name[32];
As we've discussed, band name can be inferred from the frequency.
Also, there are more than one name for the same band (it could be
named based on the wavelength or frequency - also, some bands or
band segments may have special names, like Tropical Wave).
Let's userspace just call it whatever it wants. So, I'll just
drop it.
On the other hand, the modulation is independent on the band, and
ITU-R and regulator agencies may allow more than one modulation type
and usage for the same frequency (like primary and secondary usage).
So, it makes sense to have an enum here to describe the modulation type
(currenly, AM, FM and VSB).
+ __u32 reserved[6];
};
struct v4l2_hw_freq_seek {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 seek_upward;
- __u32 wrap_around;
- __u32 spacing;
- __u32 reserved[7];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 seek_upward;
+ __u32 wrap_around;
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
@@ -2646,6 +2658,10 @@ struct v4l2_create_buffers {
#define VIDIOC_QUERY_DV_TIMINGS _IOR('V', 99, struct v4l2_dv_timings)
#define VIDIOC_DV_TIMINGS_CAP _IOWR('V', 100, struct v4l2_dv_timings_cap)
+/* Experimental, this ioctl may change over the next couple of kernel
+ versions. */
+#define VIDIOC_ENUM_FREQ_BANDS _IOWR('V', 101, struct
v4l2_frequency_band)
+
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
