cx24116 for 16APSK
Hi, Does anyone know how to tune cx24116 based card for 16apsk modulation? BR/KH Jonathan Swift - May you live every day of your life. - http://www.brainyquote.com/quotes/authors/j/jonathan_swift.html -- 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: uvcvideo causes ehci_hcd to halt
Alan Stern wrote On 22-10-2009 04:36: On Thu, 22 Oct 2009, Laurent Pinchart wrote: Here's the outputs from /sys/kernel/debug/usb/ehci: periodic: size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) registers: bus pci, device :00:1d.7 EHCI Host Controller EHCI 1.00, hcd state 0 ownership 0001 SMI sts/enable 0x8008 structural params 0x00104208 capability params 0x00016871 status 6008 Periodic Recl FLR command 01 (park)=0 ithresh=1 period=1024 HALT intrenable 00 uframe 2fa0 port 1 status 001000 POWER sig=se0 port 2 status 001000 POWER sig=se0 port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 port 5 status 001005 POWER sig=se0 PE CONNECT port 6 status 001005 POWER sig=se0 PE CONNECT port 7 status 001000 POWER sig=se0 port 8 status 001000 POWER sig=se0 irq normal 60 err 0 reclaim 16 (lost 0) complete 60 unlink 1 -- 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
[linux-dvb] Corrupted image with budget DBV-T card (WinTV NOVA-T Stick)
Hello! I've got a WinTV NOVA T Stick, working flawlessly on buth windows and linux but as soon as I connect an external HDD, I start getting a corrupted image on linux but not on windows. What could be done to fix this issue? I use xine to watch the channels on linux and ProgDVB on windows. cya! -- 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
[PATCH net-next-2.6 0/4] net: change the way mc_list is accessed
In a struct net_device, multicast addresses are stored using a self-made linked list. To convert this to list_head list there would be needed to do the change in all (literally all) network device drivers at once. To solve this situation and also to make device drivers' code prettier I'm introducing several multicast list helpers which can (and in the future they should) be used to access mc list. Once all drivers will use these helpers, we can easily convert to list_head. The part of this patchset are also 3 examples of a usage of the helpers. Kindly asking for review. Thanks, Jirka -- 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
[PATCH net-next-2.6 1/4] net: introduce mc list helpers
This helpers should be used by network drivers to access to netdev
multicast lists.
Signed-off-by: Jiri Pirko jpi...@redhat.com
---
include/linux/netdevice.h | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8380009..7edc4a6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -921,6 +921,28 @@ struct net_device
#defineNETDEV_ALIGN32
+static inline int netdev_mc_count(struct net_device *dev)
+{
+ return dev-mc_count;
+}
+
+static inline bool netdev_mc_empty(struct net_device *dev)
+{
+ return netdev_mc_count(dev) == 0;
+}
+
+static inline void netdev_mc_walk(struct net_device *dev,
+ void (*func)(void *, unsigned char *),
+ void *data)
+{
+ struct dev_addr_list *mclist;
+ int i;
+
+ for (i = 0, mclist = dev-mc_list; mclist i dev-mc_count;
+i++, mclist = mclist-next)
+ func(data, mclist-dmi_addr);
+}
+
static inline
struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
unsigned int index)
--
1.6.2.5
--
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
[PATCH net-next-2.6 2/4] 8139too: use mc helpers to access multicast list
Signed-off-by: Jiri Pirko jpi...@redhat.com
---
drivers/net/8139too.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 7e333f7..f0c3670 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -2501,6 +2501,15 @@ static struct net_device_stats *rtl8139_get_stats
(struct net_device *dev)
return dev-stats;
}
+static void mc_walker(void *data, unsigned char *addr)
+{
+ u32 *mc_filter = data;
+ int bit_nr;
+
+ bit_nr = ether_crc(ETH_ALEN, addr) 26;
+ mc_filter[bit_nr 5] |= 1 (bit_nr 31);
+}
+
/* Set or clear the multicast filter for this adaptor.
This routine is not state sensitive and need not be SMP locked. */
@@ -2509,7 +2518,7 @@ static void __set_rx_mode (struct net_device *dev)
struct rtl8139_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp-mmio_addr;
u32 mc_filter[2]; /* Multicast hash filter */
- int i, rx_mode;
+ int rx_mode;
u32 tmp;
pr_debug(%s: rtl8139_set_rx_mode(%4.4x) done -- Rx config %8.8lx.\n,
@@ -2521,22 +2530,17 @@ static void __set_rx_mode (struct net_device *dev)
AcceptBroadcast | AcceptMulticast | AcceptMyPhys |
AcceptAllPhys;
mc_filter[1] = mc_filter[0] = 0x;
- } else if ((dev-mc_count multicast_filter_limit)
+ } else if ((netdev_mc_count(dev) multicast_filter_limit)
|| (dev-flags IFF_ALLMULTI)) {
/* Too many to filter perfectly -- accept all multicasts. */
rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys;
mc_filter[1] = mc_filter[0] = 0x;
} else {
- struct dev_mc_list *mclist;
rx_mode = AcceptBroadcast | AcceptMyPhys;
- mc_filter[1] = mc_filter[0] = 0;
- for (i = 0, mclist = dev-mc_list; mclist i dev-mc_count;
-i++, mclist = mclist-next) {
- int bit_nr = ether_crc(ETH_ALEN, mclist-dmi_addr)
26;
-
- mc_filter[bit_nr 5] |= 1 (bit_nr 31);
+ if (!netdev_mc_empty(dev))
rx_mode |= AcceptMulticast;
- }
+ mc_filter[1] = mc_filter[0] = 0;
+ netdev_mc_walk(dev, mc_walker, mc_filter);
}
/* We can safely update without stopping the chip. */
--
1.6.2.5
--
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
[PATCH net-next-2.6 3/4] e1000e: use mc helpers to access multicast list
Signed-off-by: Jiri Pirko jpi...@redhat.com
---
drivers/net/e1000e/netdev.c | 34 +++---
1 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 3769248..97cd106 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -2529,6 +2529,17 @@ static void e1000_update_mc_addr_list(struct e1000_hw
*hw, u8 *mc_addr_list,
}
/**
+ * e1000_mc_walker - helper function
+ **/
+static void e1000_mc_walker(void *data, unsigned char *addr)
+{
+ u8 **mta_list_i = data;
+
+ memcpy(*mta_list_i, addr, ETH_ALEN);
+ *mta_list_i += ETH_ALEN;
+}
+
+/**
* e1000_set_multi - Multicast and Promiscuous mode set
* @netdev: network interface device structure
*
@@ -2542,10 +2553,9 @@ static void e1000_set_multi(struct net_device *netdev)
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = adapter-hw;
struct e1000_mac_info *mac = hw-mac;
- struct dev_mc_list *mc_ptr;
- u8 *mta_list;
+ u8 *mta_list, *mta_list_i;
u32 rctl;
- int i;
+ int mc_count;
/* Check for Promiscuous and All Multicast modes */
@@ -2567,23 +2577,17 @@ static void e1000_set_multi(struct net_device *netdev)
ew32(RCTL, rctl);
- if (netdev-mc_count) {
- mta_list = kmalloc(netdev-mc_count * 6, GFP_ATOMIC);
+ mc_count = netdev_mc_count(netdev);
+ if (mc_count) {
+ mta_list = kmalloc(mc_count * ETH_ALEN, GFP_ATOMIC);
if (!mta_list)
return;
/* prepare a packed array of only addresses. */
- mc_ptr = netdev-mc_list;
-
- for (i = 0; i netdev-mc_count; i++) {
- if (!mc_ptr)
- break;
- memcpy(mta_list + (i*ETH_ALEN), mc_ptr-dmi_addr,
- ETH_ALEN);
- mc_ptr = mc_ptr-next;
- }
+ mta_list_i = mta_list;
+ netdev_mc_walk(netdev, e1000_mc_walker, mta_list_i);
- e1000_update_mc_addr_list(hw, mta_list, i, 1,
+ e1000_update_mc_addr_list(hw, mta_list, mc_count, 1,
mac-rar_entry_count);
kfree(mta_list);
} else {
--
1.6.2.5
--
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: [PATCH net-next-2.6 0/4] net: change the way mc_list is accessed
Signed-off-by: Jiri Pirko jpi...@redhat.com
---
drivers/media/dvb/dvb-core/dvb_net.c | 22 +++---
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 8c9ae0a..eb50fb0 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -1110,17 +1110,16 @@ static int dvb_net_feed_stop(struct net_device *dev)
}
-static int dvb_set_mc_filter (struct net_device *dev, struct dev_mc_list *mc)
+static void dvb_set_mc_filter(void *data, unsigned char *addr)
{
- struct dvb_net_priv *priv = netdev_priv(dev);
+ struct dvb_net_priv *priv = data;
if (priv-multi_num == DVB_NET_MULTICAST_MAX)
- return -ENOMEM;
+ return;
- memcpy(priv-multi_macs[priv-multi_num], mc-dmi_addr, 6);
+ memcpy(priv-multi_macs[priv-multi_num], addr, ETH_ALEN);
priv-multi_num++;
- return 0;
}
@@ -1140,21 +1139,14 @@ static void wq_set_multicast_list (struct work_struct
*work)
} else if ((dev-flags IFF_ALLMULTI)) {
dprintk(%s: allmulti mode\n, dev-name);
priv-rx_mode = RX_MODE_ALL_MULTI;
- } else if (dev-mc_count) {
- int mci;
- struct dev_mc_list *mc;
-
+ } else if (netdev_mc_count(dev)) {
dprintk(%s: set_mc_list, %d entries\n,
- dev-name, dev-mc_count);
+ dev-name, netdev_mc_count(dev));
priv-rx_mode = RX_MODE_MULTI;
priv-multi_num = 0;
- for (mci = 0, mc=dev-mc_list;
-mci dev-mc_count;
-mc = mc-next, mci++) {
- dvb_set_mc_filter(dev, mc);
- }
+ netdev_mc_walk(dev, dvb_set_mc_filter, priv);
}
netif_addr_unlock_bh(dev);
--
1.6.2.5
--
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: [PATCH net-next-2.6 0/4] net: change the way mc_list is accessed
wrong subject... reposting...
Thu, Oct 22, 2009 at 03:54:47PM CEST, jpi...@redhat.com wrote:
Signed-off-by: Jiri Pirko jpi...@redhat.com
---
drivers/media/dvb/dvb-core/dvb_net.c | 22 +++---
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 8c9ae0a..eb50fb0 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -1110,17 +1110,16 @@ static int dvb_net_feed_stop(struct net_device *dev)
}
-static int dvb_set_mc_filter (struct net_device *dev, struct dev_mc_list *mc)
+static void dvb_set_mc_filter(void *data, unsigned char *addr)
{
- struct dvb_net_priv *priv = netdev_priv(dev);
+ struct dvb_net_priv *priv = data;
if (priv-multi_num == DVB_NET_MULTICAST_MAX)
- return -ENOMEM;
+ return;
- memcpy(priv-multi_macs[priv-multi_num], mc-dmi_addr, 6);
+ memcpy(priv-multi_macs[priv-multi_num], addr, ETH_ALEN);
priv-multi_num++;
- return 0;
}
@@ -1140,21 +1139,14 @@ static void wq_set_multicast_list (struct work_struct
*work)
} else if ((dev-flags IFF_ALLMULTI)) {
dprintk(%s: allmulti mode\n, dev-name);
priv-rx_mode = RX_MODE_ALL_MULTI;
- } else if (dev-mc_count) {
- int mci;
- struct dev_mc_list *mc;
-
+ } else if (netdev_mc_count(dev)) {
dprintk(%s: set_mc_list, %d entries\n,
- dev-name, dev-mc_count);
+ dev-name, netdev_mc_count(dev));
priv-rx_mode = RX_MODE_MULTI;
priv-multi_num = 0;
- for (mci = 0, mc=dev-mc_list;
- mci dev-mc_count;
- mc = mc-next, mci++) {
- dvb_set_mc_filter(dev, mc);
- }
+ netdev_mc_walk(dev, dvb_set_mc_filter, priv);
}
netif_addr_unlock_bh(dev);
--
1.6.2.5
--
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
[PATCH net-next-2.6 4/4] dvb: dvb_net: use mc helpers to access multicast list
Signed-off-by: Jiri Pirko jpi...@redhat.com
---
drivers/media/dvb/dvb-core/dvb_net.c | 22 +++---
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 8c9ae0a..eb50fb0 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -1110,17 +1110,16 @@ static int dvb_net_feed_stop(struct net_device *dev)
}
-static int dvb_set_mc_filter (struct net_device *dev, struct dev_mc_list *mc)
+static void dvb_set_mc_filter(void *data, unsigned char *addr)
{
- struct dvb_net_priv *priv = netdev_priv(dev);
+ struct dvb_net_priv *priv = data;
if (priv-multi_num == DVB_NET_MULTICAST_MAX)
- return -ENOMEM;
+ return;
- memcpy(priv-multi_macs[priv-multi_num], mc-dmi_addr, 6);
+ memcpy(priv-multi_macs[priv-multi_num], addr, ETH_ALEN);
priv-multi_num++;
- return 0;
}
@@ -1140,21 +1139,14 @@ static void wq_set_multicast_list (struct work_struct
*work)
} else if ((dev-flags IFF_ALLMULTI)) {
dprintk(%s: allmulti mode\n, dev-name);
priv-rx_mode = RX_MODE_ALL_MULTI;
- } else if (dev-mc_count) {
- int mci;
- struct dev_mc_list *mc;
-
+ } else if (netdev_mc_count(dev)) {
dprintk(%s: set_mc_list, %d entries\n,
- dev-name, dev-mc_count);
+ dev-name, netdev_mc_count(dev));
priv-rx_mode = RX_MODE_MULTI;
priv-multi_num = 0;
- for (mci = 0, mc=dev-mc_list;
-mci dev-mc_count;
-mc = mc-next, mci++) {
- dvb_set_mc_filter(dev, mc);
- }
+ netdev_mc_walk(dev, dvb_set_mc_filter, priv);
}
netif_addr_unlock_bh(dev);
--
1.6.2.5
--
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: uvcvideo causes ehci_hcd to halt
On Thu, 22 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote:
Here's the outputs from /sys/kernel/debug/usb/ehci:
periodic:
size = 1024
1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8)
There's something odd about this. I'd like to see this file again,
after the patch below has been applied.
registers:
bus pci, device :00:1d.7
EHCI Host Controller
EHCI 1.00, hcd state 0
ownership 0001
SMI sts/enable 0x8008
structural params 0x00104208
capability params 0x00016871
status 6008 Periodic Recl FLR
command 01 (park)=0 ithresh=1 period=1024 HALT
intrenable 00
uframe 2fa0
port 1 status 001000 POWER sig=se0
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
port 5 status 001005 POWER sig=se0 PE CONNECT
port 6 status 001005 POWER sig=se0 PE CONNECT
port 7 status 001000 POWER sig=se0
port 8 status 001000 POWER sig=se0
irq normal 60 err 0 reclaim 16 (lost 0)
complete 60 unlink 1
This confirms that the periodic schedule was never disabled.
So first get another copy of the periodic file with the patch below.
Then try changing the enable_periodic() routine in ehci-sched.c: Add
udelay(2000);
just before the final return 0; line. Let's see if that prevents the
problem from occurring.
Alan Stern
--- usb-2.6.orig/drivers/usb/host/ehci-dbg.c
+++ usb-2.6/drivers/usb/host/ehci-dbg.c
@@ -591,18 +591,21 @@ static ssize_t fill_periodic_buffer(stru
qtd-hw_token) 8)) {
case 0: type = out; continue;
case 1: type = in; continue;
+ case 2: type = ?2; continue;
+ case 3: type = ?3; continue;
}
}
temp = scnprintf (next, size,
(%c%d ep%d%s
- [%d/%d] q%d p%d),
+ [%d/%d] q%d p%d) %08x,
speed_char (scratch),
scratch 0x007f,
(scratch 8) 0x000f, type,
p.qh-usecs, p.qh-c_usecs,
temp,
- 0x7ff (scratch 16));
+ 0x7ff (scratch 16),
+ hc32_to_cpu(ehci,
qtd-hw_token));
if (seen_count DBG_SCHED_LIMIT)
seen [seen_count++].qh = p.qh;
--
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: [PATCH net-next-2.6 1/4] net: introduce mc list helpers
Thu, Oct 22, 2009 at 04:18:32PM CEST, bhutchi...@solarflare.com wrote:
On Thu, 2009-10-22 at 15:52 +0200, Jiri Pirko wrote:
This helpers should be used by network drivers to access to netdev
multicast lists.
[...]
+static inline void netdev_mc_walk(struct net_device *dev,
+ void (*func)(void *, unsigned char *),
+ void *data)
+{
+struct dev_addr_list *mclist;
+int i;
+
+for (i = 0, mclist = dev-mc_list; mclist i dev-mc_count;
+ i++, mclist = mclist-next)
+func(data, mclist-dmi_addr);
+}
[...]
We usually implement iteration as macros so that any context doesn't
have to be squeezed through a single untyped (void *) variable. A macro
for this would look something like:
#define netdev_for_each_mc_addr(dev, addr)
\
for (addr = (dev)-mc_list ? (dev)-mc_list-dmi_addr : NULL;
\
addr;
\
addr = (container_of(addr, struct dev_addr_list, dmi_addr)-next ?
\
container_of(addr, struct dev_addr_list,
dmi_addr)-next-dmi_addr : \
NULL))
I admit this would look better. Going to change this and then repost.
Thanks Ben
Once you change the list type this can presumably be made less ugly.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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: [PATCH net-next-2.6 1/4] net: introduce mc list helpers
On Thu, 2009-10-22 at 15:52 +0200, Jiri Pirko wrote:
This helpers should be used by network drivers to access to netdev
multicast lists.
[...]
+static inline void netdev_mc_walk(struct net_device *dev,
+ void (*func)(void *, unsigned char *),
+ void *data)
+{
+ struct dev_addr_list *mclist;
+ int i;
+
+ for (i = 0, mclist = dev-mc_list; mclist i dev-mc_count;
+ i++, mclist = mclist-next)
+ func(data, mclist-dmi_addr);
+}
[...]
We usually implement iteration as macros so that any context doesn't
have to be squeezed through a single untyped (void *) variable. A macro
for this would look something like:
#define netdev_for_each_mc_addr(dev, addr)
\
for (addr = (dev)-mc_list ? (dev)-mc_list-dmi_addr : NULL;
\
addr;
\
addr = (container_of(addr, struct dev_addr_list, dmi_addr)-next ?
\
container_of(addr, struct dev_addr_list,
dmi_addr)-next-dmi_addr : \
NULL))
Once you change the list type this can presumably be made less ugly.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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
[PATCH] Support for VIDIOC_QUERYSTD in v4l2-ctl
Attached patch adds support for running the VIDIOC_QUERYSTD ioctl from v4l2-ctl. Best regards Sigmund Augdal v4l2-ctl-querystd.patch Description: Binary data
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote: On Thu, 22 Oct 2009, [UTF-8] Ozan Çağlayan wrote: Here's the outputs from /sys/kernel/debug/usb/ehci: periodic: size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) There's something odd about this. I'd like to see this file again, after the patch below has been applied. Do you want me to apply this patch altogether with the first one that you sent a while ago in this thread or directly onto the vanilla kernel? -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Oct 22 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13156:f6680fa8e7ec gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Details about DVB frontend API
On Thu, Oct 22, 2009 at 3:13 PM, Jean Delvare kh...@linux-fr.org wrote: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. Thanks, -- Jean Delvare Hi Jean, I try to raise this every six months or so. Check the mailing list archive for SNR in the subject line. Yes, it's all screwed up and inconsistent across demods. I took a crack at fixing it a few months ago by proposing a standard (and even offering to fix up all the demods to be consistent), and those efforts were derailed by some individuals who wanted what I would consider a perfect interface at the cost of something that worked for 98% of the userbase (I'm not going to point any fingers). And what did we get as a result? Nothing. I could have had this problem solved six months ago for 98% of the community, and instead we are right where we have been since the beginning of the project. /me stops thinking about this and goes and gets some coffee Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: Details about DVB frontend API
On Thu, Oct 22, 2009 at 12:27 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: I could have had this problem solved six months ago for 98% of the community, and instead we are right where we have been since the beginning of the project. This is really a shame too considering the enormous amount of people, both users devs, who would really like to see this happen. You've got to start somewhere and build/improve from there. Simply sitting back and doing nothing is of absolutely no benefit what-so-ever. Maybe you should release your patch(es) and when/if enough people use them, there will be some pressure to actually have progress. Then again, the same ugly monster that is linux dvb politics might prevent that progress from ever happening. Regards, Derek -- 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: uvcvideo causes ehci_hcd to halt
On Thu, 22 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote:
Alan Stern wrote:
On Thu, 22 Oct 2009, [UTF-8] Ozan Ãâ¡aßlayan wrote:
Here's the outputs from /sys/kernel/debug/usb/ehci:
periodic:
size = 1024
1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8)
There's something odd about this. I'd like to see this file again,
after the patch below has been applied.
Do you want me to apply this patch altogether with the first one that
you sent a while ago in this thread or directly onto the vanilla kernel?
It doesn't matter. The size = 1024 line in your debugging output
means that the first patch won't have any effect; my hunch was wrong.
However it turns out that the most recent patch wasn't quite what I
wanted. Here's an updated version to be used instead.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci-dbg.c
===
--- usb-2.6.orig/drivers/usb/host/ehci-dbg.c
+++ usb-2.6/drivers/usb/host/ehci-dbg.c
@@ -596,18 +596,22 @@ static ssize_t fill_periodic_buffer(stru
qtd-hw_token) 8)) {
case 0: type = out; continue;
case 1: type = in; continue;
+ case 2: type = ?2; continue;
+ case 3: type = ?3; continue;
}
}
temp = scnprintf (next, size,
(%c%d ep%d%s
- [%d/%d] q%d p%d),
+ [%d/%d] q%d p%d) t%08x,
speed_char (scratch),
scratch 0x007f,
(scratch 8) 0x000f, type,
p.qh-usecs, p.qh-c_usecs,
temp,
- 0x7ff (scratch 16));
+ 0x7ff (scratch 16),
+ hc32_to_cpu(ehci,
+ p.qh-hw-hw_token));
if (seen_count DBG_SCHED_LIMIT)
seen [seen_count++].qh = p.qh;
--
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: Details about DVB frontend API
Em Thu, 22 Oct 2009 21:13:30 +0200 Jean Delvare kh...@linux-fr.org escreveu: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. We all want to know about that ;) Seriously, the lack of a description of the meaning of the ranges for those read values were already widely discussed at LMML and at the legacy dvb ML. We should return this discussion again and decide what would be the better way to describe those values. My suggestion is that someone summarize the proposals we had and give some time for people vote. After that, we just commit the most voted one, and commit the patches for it. A pending question that should also be discussed is what we will do with those dvb devices where we simply don't know what scale it uses. There are several of them. Btw, the new official documentation is the media infrastructure docbook that can be found at the Kernel and at: http://linuxtv.org/downloads/v4l-dvb-apis This covers both DVB and V4L API's. Cheers, Mauro -- 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: Details about DVB frontend API
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit the
patches for it. A pending question that should also be discussed is what we
will
do with those dvb devices where we simply don't know what scale it uses. There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
Regards,
Manu
diff -r b5505a985f24 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Tue Apr 07 18:19:22 2009 +0400
@@ -1004,8 +1004,8 @@
*/
/* Legacy */
if (fe-legacy) {
- if ((fepriv-state FESTATE_LOSTLOCK)
- (fe-ops.info.caps FE_CAN_RECOVER)
+ if ((fepriv-state FESTATE_LOSTLOCK)
+ (fe-ops.info.caps FE_CAN_RECOVER)
(fepriv-max_drift == 0)) {
dvb_frontend_swzigzag_update_delay(fepriv, s FE_HAS_LOCK);
@@ -1487,6 +1487,13 @@
break;
}
+ case FE_STATISTICS_CAPS: {
+ struct fecap_statistics *stats_cap = parg;
+ memcpy(stats_cap, fe-ops.statistics_caps, sizeof (struct fecap_statistics));
+ err = 0;
+ break;
+ }
+
case FE_READ_STATUS: {
fe_status_t* status = parg;
@@ -1502,6 +1509,17 @@
err = fe-ops.read_status(fe, status);
break;
}
+
+ case FE_SIGNAL_LEVEL:
+ if (fe-ops.read_level)
+ err = fe-ops.read_level(fe, (__u32 *) parg);
+ break;
+
+ case FE_SIGNAL_STATS:
+ if (fe-ops.read_stats)
+ err = fe-ops.read_stats(fe, (struct fesignal_stat *) parg);
+ break;
+
case FE_READ_BER:
if (fe-ops.read_ber)
err = fe-ops.read_ber(fe, (__u32*) parg);
@@ -1645,7 +1663,7 @@
break;
}
- memcpy(fepriv-parameters, parg, sizeof (struct dvb_frontend_parameters));
+ memcpy(fepriv-parameters, parg, sizeof (struct dvb_frontend_parameters));
memset(fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
memcpy(fetunesettings.parameters, parg, sizeof (struct dvb_frontend_parameters));
diff -r b5505a985f24 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Tue Apr 07 18:19:22 2009 +0400
@@ -72,7 +72,7 @@
unsigned int audmode;
u64 std;
};
-
+
enum dvbfe_modcod {
DVBFE_MODCOD_DUMMY_PLFRAME = 0,
DVBFE_MODCOD_QPSK_1_4,
@@ -250,6 +250,7 @@
struct dvb_frontend_ops {
struct dvb_frontend_info info;
+ struct fecap_statistics statistics_caps;
void (*release)(struct dvb_frontend* fe);
void (*release_sec)(struct dvb_frontend* fe);
@@ -304,6 +305,9 @@
enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvbfe_params *fe_params);
int (*track)(struct dvb_frontend *fe, struct dvbfe_params *fe_params, int *delay);
+ int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */
+ int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat);
+
struct dvb_tuner_ops tuner_ops;
struct analog_demod_ops analog_ops;
};
diff -r b5505a985f24
Re: [PATCH] Support for VIDIOC_QUERYSTD in v4l2-ctl
Attached patch adds support for running the VIDIOC_QUERYSTD ioctl from v4l2-ctl. Best regards Sigmund Augdal Thanks! This looks good to me. Signed-off-by: Hans Verkuil hverk...@xs4all.nl -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PATCH] output human readable form of the .status field from VIDIOC_ENUMINPUT
The attach patch modifies v4l2-ctl -I to also output signal status as detected by the driver/hardware. This info is available in the status field of the data returned by VIDIOC_ENUMINPUT which v4l2-ctl -I already calls. The strings are copied from the v4l2 api specification and could perhaps be modified a bit to fit the application. Best regards Sigmund Augdal Hi Sigmund, This doesn't work right: the status field is a bitmask, so multiple bits can be set at the same time. So a switch is not the right choice for that. Look at some of the other functions to print bitmasks in v4l2-ctl.cpp for ideas on how to implement this properly. But it will be nice to have this in v4l2-ctl! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: Details about DVB frontend API
On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham abraham.m...@gmail.com wrote:
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit
the
patches for it. A pending question that should also be discussed is what we
will
do with those dvb devices where we simply don't know what scale it uses.
There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
A few of our customers were requiring additional statistic
information, so we added follwing
command to our DVB API:
FE_GET_SIGQUALITY
struct media_sigquality {
uint16_t MER; /** in steps of 0.1 dB
*/
uint32_t preViterbiBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t postViterbiBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t scaleFactorBER; /** scale factor for BER
*/
uint32_t packetError ; /** number of packet errors
*/
uint32_t postReedSolomonBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t indicator;/** indicative signal quality
low=0..100=high */
}
It's a one shot request.
it might be good to standardize this, although we can live with that
additional command too.
Best Regards,
Markus
--
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: Details about DVB frontend API
On Fri, Oct 23, 2009 at 4:12 AM, Markus Rechberger
mrechber...@gmail.com wrote:
On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham abraham.m...@gmail.com wrote:
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit
the
patches for it. A pending question that should also be discussed is what we
will
do with those dvb devices where we simply don't know what scale it uses.
There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
A few of our customers were requiring additional statistic
information, so we added follwing
command to our DVB API:
FE_GET_SIGQUALITY
struct media_sigquality {
uint16_t MER; /** in steps of 0.1 dB
*/
uint32_t preViterbiBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t postViterbiBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t scaleFactorBER; /** scale factor for BER
*/
uint32_t packetError ; /** number of packet errors
*/
uint32_t postReedSolomonBER ; /** in steps of 1/scaleFactorBER
*/
uint32_t indicator; /** indicative signal quality
low=0..100=high */
}
It's a one shot request.
it might be good to standardize this, although we can live with that
additional command too.
Based on the above data structure, since UNC is calculated from pre -
post viterbi, any good reason why you need it explicit ? Which
otherwise is redundant. Still when simplified, it looks exactly the
same as the version 3.2 frontend statistic information alone except
for the BER scale, isn't it ?
Regards,
Manu
--
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: Details about DVB frontend API
We did discuss this briefly during the v4l-dvb mini-summit and I know Mike Krufky knew what to do about this, but for the life of me I can't remember what it was. I should have made a note of it... Mike, can you refresh my memory? You are correct Hans. Mike has some patches that begin to address this for the ATSC products, standardizing some of the unit measurements. Very clean, easy to review and merge. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: Details about DVB frontend API
On Friday 23 October 2009 06:13:30 Jean Delvare wrote: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. Thanks, I have tried on two occasions to engage the the author of my particular driver as to how to implement a patch and use femon with no response. Its good that there is some movement at last which might get a result. I've said before I don't really care too much about spot on accuracy but rather a scale that increases as you get closer to a lock. I can imagine there are loads of users out there who rely on the output of things like femon and vdr-rotor to tune their equipment and with S2 cards like both of mine they are knackered so to speak. Mike -- 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
