Re: [linux-dvb] Suspend/resume for Mantis 2033 driver
COOL!!! First driver implementing suspend/resume! Do you plan add suspend/resume also to other drivers? I can help testing dib0700/dib7000/pluto2/opera drivers Michal Dne sobota 04 srpen 2007 08:02 Marko Ristola napsal(a): > Hi Manu and all > > I have done small improvements into Mantis drivers: > I have fixed the insmod/rmmod problem and I have implemented > suspend/resume for cu1216. > It does in mantis_dvb.c "power off"/ "power on" if no application > uses the frontend. > > So with my suspend/resume and with non-USB sound output, > I am able to suspend to disk and back so that Kaffeine will > continue displaying the TV channel. > I use now 2.6.22.1-41.fc7 kernel. > > cu1216 needed only small changes with the current version. > Most changes went into dvb/mantis directory. > resume uses fe->opt.init for cu1216, so it must do something. > resume uses fe->opt.set_frontend(fe,NULL) currently, meaning > "please set the previous tuning values". > > I need to collect the patches and clean them up before sending them for > you. > > Regards, Marko Ristola > > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Suspend/resume for Mantis 2033 driver
Hi Manu and all I have done small improvements into Mantis drivers: I have fixed the insmod/rmmod problem and I have implemented suspend/resume for cu1216. It does in mantis_dvb.c "power off"/ "power on" if no application uses the frontend. So with my suspend/resume and with non-USB sound output, I am able to suspend to disk and back so that Kaffeine will continue displaying the TV channel. I use now 2.6.22.1-41.fc7 kernel. cu1216 needed only small changes with the current version. Most changes went into dvb/mantis directory. resume uses fe->opt.init for cu1216, so it must do something. resume uses fe->opt.set_frontend(fe,NULL) currently, meaning "please set the previous tuning values". I need to collect the patches and clean them up before sending them for you. Regards, Marko Ristola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On 8/4/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > On 8/4/07, Michael Krufky <[EMAIL PROTECTED]> wrote: > > Manu Abraham wrote: > > > On 8/4/07, Janne Grunau <[EMAIL PROTECTED]> wrote: > > >> On Saturday 04 August 2007 00:02:29 Manu Abraham wrote: > > >>> Do we really want to have adapter numbers in DVB bridge drivers ? > > >>> IMHO, it doesn't look pleasing to have that. > > >> I think it's worthwhile to have it. > > >>> Is there any other possible better alternatives ? > > >> Something similiar is possible with udev rules but I wouldn't say that > > >> it is a better alternative. > > > > > > Why ? If you can achieve the same without any code change, doesn't > > > that look better ? > > > > using a module option to specify adapter number is a _much_ more user > > friendly solution, as opposed to udev rules. > > > > > Yuck. I just wonder why other char drivers in the Linux kernel do not > have such a necessity, you have the same problem there as well. btw, though not directly related this thread on LK deals with the same root cause http://lkml.org/lkml/2007/8/2/82 (got late, must run now) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On 8/4/07, Michael Krufky <[EMAIL PROTECTED]> wrote: > Manu Abraham wrote: > > On 8/4/07, Janne Grunau <[EMAIL PROTECTED]> wrote: > >> On Saturday 04 August 2007 00:02:29 Manu Abraham wrote: > >>> Do we really want to have adapter numbers in DVB bridge drivers ? > >>> IMHO, it doesn't look pleasing to have that. > >> I think it's worthwhile to have it. > >>> Is there any other possible better alternatives ? > >> Something similiar is possible with udev rules but I wouldn't say that > >> it is a better alternative. > > > > Why ? If you can achieve the same without any code change, doesn't > > that look better ? > > using a module option to specify adapter number is a _much_ more user > friendly solution, as opposed to udev rules. > Yuck. I just wonder why other char drivers in the Linux kernel do not have such a necessity, you have the same problem there as well. > >>> If it is that > >>> absolute a necessity, can we hide the ugliness in dvb-core at least ? > >> I'm not really sure what you mean exactly. If you want to avoid changes > >> in the bridge drivers I don't see a way to archieve that. If you want > >> the changes as small as possible look at the final patch. > > > > That one looks better than your first patch. (Although i hate having a > > MAX limit defined) > > The MAX limit was already there beforehand -- Janne only moved the setting of > it from dvbdev.c to dvbdev.h. > That cruft/limit comes from the old allocation. The v2.4 kernel supported only 255 major devices with 255 minor numbers. Larger devices have been a feature that 2.6 brought forward. Though we have had this number incremented a while later on, we still have some cruft in there. That limitation comes in the form of that limitation, though if someone wants to have more devices having to tweak MAX_DEVICES, :-/ Having limitations that way is not quite nice. That brings up the old devfs vs udev memories http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
Manu Abraham wrote: > On 8/4/07, Janne Grunau <[EMAIL PROTECTED]> wrote: >> On Saturday 04 August 2007 00:02:29 Manu Abraham wrote: >>> Do we really want to have adapter numbers in DVB bridge drivers ? >>> IMHO, it doesn't look pleasing to have that. >> I think it's worthwhile to have it. >>> Is there any other possible better alternatives ? >> Something similiar is possible with udev rules but I wouldn't say that >> it is a better alternative. > > Why ? If you can achieve the same without any code change, doesn't > that look better ? using a module option to specify adapter number is a _much_ more user friendly solution, as opposed to udev rules. >>> If it is that >>> absolute a necessity, can we hide the ugliness in dvb-core at least ? >> I'm not really sure what you mean exactly. If you want to avoid changes >> in the bridge drivers I don't see a way to archieve that. If you want >> the changes as small as possible look at the final patch. > > That one looks better than your first patch. (Although i hate having a > MAX limit defined) The MAX limit was already there beforehand -- Janne only moved the setting of it from dvbdev.c to dvbdev.h. > I meant adding a module parameter to each module, which was a bit, .. > I don't know how come others said that they liked the first one very > much. I liked the concept... of course the macro is much cleaner looking. >> One line for >> the module parameter and the added parameter for the register function. >> I don't think it can be done with less changes. > > > True. -MiKE ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On 8/4/07, Janne Grunau <[EMAIL PROTECTED]> wrote: > On Saturday 04 August 2007 00:02:29 Manu Abraham wrote: > > > > Do we really want to have adapter numbers in DVB bridge drivers ? > > IMHO, it doesn't look pleasing to have that. > > I think it's worthwhile to have it. > > > > Is there any other possible better alternatives ? > > Something similiar is possible with udev rules but I wouldn't say that > it is a better alternative. Why ? If you can achieve the same without any code change, doesn't that look better ? > > If it is that > > absolute a necessity, can we hide the ugliness in dvb-core at least ? > > I'm not really sure what you mean exactly. If you want to avoid changes > in the bridge drivers I don't see a way to archieve that. If you want > the changes as small as possible look at the final patch. That one looks better than your first patch. (Although i hate having a MAX limit defined) I meant adding a module parameter to each module, which was a bit, .. I don't know how come others said that they liked the first one very much. > One line for > the module parameter and the added parameter for the register function. > I don't think it can be done with less changes. True. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On Saturday 04 August 2007 00:02:29 Manu Abraham wrote: > > Do we really want to have adapter numbers in DVB bridge drivers ? > IMHO, it doesn't look pleasing to have that. I think it's worthwhile to have it. > > Is there any other possible better alternatives ? Something similiar is possible with udev rules but I wouldn't say that it is a better alternative. > If it is that > absolute a necessity, can we hide the ugliness in dvb-core at least ? I'm not really sure what you mean exactly. If you want to avoid changes in the bridge drivers I don't see a way to archieve that. If you want the changes as small as possible look at the final patch. One line for the module parameter and the added parameter for the register function. I don't think it can be done with less changes. Janne ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
Manu Abraham wrote:
> On 8/2/07, Janne Grunau <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
>> result in deterministic dvb adapter numbers.
>>
>> V4L drivers have the {radio|vbi|video}_nr module options to allocate
>> static minor numbers per driver.
>> Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
>> problems with device unplugging and repluging each driver holds
>> a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
>> options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
>> reversed allocation of adapter numbers.
>> With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
>> are already in use it will allocate the lowest free adapter number.
>>
>> Besides following changes in dvb-core and dvb-usb core the patch adds to
>> all drivers
>>
>> +static int adapter_nr[] = {[0 ... (DVB_MAX_ADAPTERS - 1)] = DVB_UNSET };
>> +module_param_array(adapter_nr, int, NULL, 0444);
>> +MODULE_PARM_DESC(adapter_nr,"DVB adapter numbers");
>>
>> and modifies the dvb_register_adapter call. Full patch is attached as
>> compressed file.
>
> Do we really want to have adapter numbers in DVB bridge drivers ?
> IMHO, it doesn't look pleasing to have that.
>
> Is there any other possible better alternatives ? If it is that
> absolute a necessity, can we hide the ugliness in dvb-core at least ?
>
> (Although dvb-core is becoming a nightmare, with lot of cruft, i don't
> see anything that's going to clear up any time soon, but rather
> increase over time, with backward compatibility and things like that)
Manu,
Please see Janne's latest patch. Does that satisfy your concern? Rather than
adding the repeated code in every driver, he used a macro, and things look quite
clean.
I like this a lot, and I'd like to commit it, if nobody speaks against it.
Would you say it's fair if I wait until Sunday before doing so?
Regards,
Michael Krufky
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On Friday 03 August 2007 21:28:01 Michael Krufky wrote:
> I say Janne should continue on and convert the rest of the drivers...
> Is anybody opposed?
done
Janne
Adds adapter_nr module parameter to all dvb drivers to specify the
preferred allocation of device minor numbers per driver.
Signed-off-by: Janne Grunau <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/b2c2/flexcop.c
+++ v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop.c
@@ -64,10 +64,10 @@ static int flexcop_dvb_stop_feed(struct
return flexcop_pid_feed_control(fc,dvbdmxfeed,0);
}
-static int flexcop_dvb_init(struct flexcop_device *fc)
+static int flexcop_dvb_init(struct flexcop_device *fc, int *adapter_nums)
{
int ret;
- if ((ret = dvb_register_adapter(&fc->dvb_adapter,"FlexCop Digital TV device",fc->owner,fc->dev)) < 0) {
+ if ((ret = dvb_register_adapter(&fc->dvb_adapter,"FlexCop Digital TV device",fc->owner,fc->dev,adapter_nums)) < 0) {
err("error registering DVB adapter");
return ret;
}
@@ -243,7 +243,7 @@ void flexcop_device_kfree(struct flexcop
}
EXPORT_SYMBOL(flexcop_device_kfree);
-int flexcop_device_initialize(struct flexcop_device *fc)
+int flexcop_device_initialize(struct flexcop_device *fc, int *adapter_nums)
{
int ret;
ibi_zero.raw = 0;
@@ -255,7 +255,7 @@ int flexcop_device_initialize(struct fle
flexcop_smc_ctrl(fc, 0);
- if ((ret = flexcop_dvb_init(fc)))
+ if ((ret = flexcop_dvb_init(fc, adapter_nums)))
goto error;
/* do the MAC address reading after initializing the dvb_adapter */
Index: v4l-dvb/linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ v4l-dvb/linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -42,6 +42,8 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Turn on/off debugging (default:off).");
+DVB_ADAPTER_NR_MODULE_PARAM
+
#define dprintk( args... ) \
do \
if (debug) printk(KERN_DEBUG args); \
@@ -717,7 +719,7 @@ static int __devinit dvb_bt8xx_load_card
{
int result;
- if ((result = dvb_register_adapter(&card->dvb_adapter, card->card_name, THIS_MODULE, &card->bt->dev->dev)) < 0) {
+ if ((result = dvb_register_adapter(&card->dvb_adapter, card->card_name, THIS_MODULE, &card->bt->dev->dev, adapter_nr)) < 0) {
printk("dvb_bt8xx: dvb_register_adapter failed (errno = %d)\n", result);
return result;
}
Index: v4l-dvb/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
+++ v4l-dvb/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
@@ -61,6 +61,8 @@ static int debug;
module_param_named(debug, debug, int, 0644);
MODULE_PARM_DESC(debug, "Turn on/off debugging (default:off).");
+DVB_ADAPTER_NR_MODULE_PARAM
+
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,15)
#define dprintk(level, args...) \
do { \
@@ -992,7 +994,7 @@ static int cinergyt2_probe (struct usb_i
return -ENOMEM;
}
- if ((err = dvb_register_adapter(&cinergyt2->adapter, DRIVER_NAME, THIS_MODULE, &cinergyt2->udev->dev)) < 0) {
+ if ((err = dvb_register_adapter(&cinergyt2->adapter, DRIVER_NAME, THIS_MODULE, &cinergyt2->udev->dev, adapter_nr)) < 0) {
kfree(cinergyt2);
return err;
}
Index: v4l-dvb/linux/drivers/media/dvb/dvb-core/dvbdev.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvbdev.c
+++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvbdev.c
@@ -53,7 +53,6 @@ static const char * const dnames[] = {
"net", "osd"
};
-#define DVB_MAX_ADAPTERS 8
#define DVB_MAX_IDS 4
#define nums2minor(num,type,id) ((num << 6) | (id << 4) | type)
#define MAX_DVB_MINORS (DVB_MAX_ADAPTERS*64)
@@ -286,21 +285,25 @@ void dvb_unregister_device(struct dvb_de
}
EXPORT_SYMBOL(dvb_unregister_device);
+static int dvbdev_check_free_adapter_num(int num)
+{
+ struct list_head *entry;
+ list_for_each (entry, &dvb_adapter_list) {
+ struct dvb_adapter *adap;
+ adap = list_entry (entry, struct dvb_adapter, list_head);
+if (adap->num == num)
+ return 0;
+ }
+return 1;
+}
static int dvbdev_get_free_adapter_num (void)
{
int num = 0;
while (num < DVB_MAX_ADAPTERS) {
- struct list_head *entry;
- list_for_each (entry, &dvb_adapter_list) {
- struct dvb_adapter *adap;
- adap = list_entry (entry, struct dvb_adapter, list_head);
- if (adap->num == num)
-goto skip;
- }
- return num;
-skip:
+ if (dvbdev_check_free_adapter_num(num))
+ return num;
num++;
}
@@ -308,13 +311,27 @@ skip:
}
-int dvb_register_adapter(struct dvb_adapter *adap, const char *name, struct module *module, struct device *device)
+int dvb_register_adapter(struct dvb_adapter *adap, const char *name, struct module *module, str
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On 8/2/07, Janne Grunau <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
> result in deterministic dvb adapter numbers.
>
> V4L drivers have the {radio|vbi|video}_nr module options to allocate
> static minor numbers per driver.
> Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
> problems with device unplugging and repluging each driver holds
> a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
> options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
> reversed allocation of adapter numbers.
> With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
> are already in use it will allocate the lowest free adapter number.
>
> Besides following changes in dvb-core and dvb-usb core the patch adds to
> all drivers
>
> +static int adapter_nr[] = {[0 ... (DVB_MAX_ADAPTERS - 1)] = DVB_UNSET };
> +module_param_array(adapter_nr, int, NULL, 0444);
> +MODULE_PARM_DESC(adapter_nr,"DVB adapter numbers");
>
> and modifies the dvb_register_adapter call. Full patch is attached as
> compressed file.
Do we really want to have adapter numbers in DVB bridge drivers ?
IMHO, it doesn't look pleasing to have that.
Is there any other possible better alternatives ? If it is that
absolute a necessity, can we hide the ugliness in dvb-core at least ?
(Although dvb-core is becoming a nightmare, with lot of cruft, i don't
see anything that's going to clear up any time soon, but rather
increase over time, with backward compatibility and things like that)
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driverspecific module option
> I like this a lot -- In fact, I think I love it. I don't have anything > negative > to say about this at all. I've always wanted a module option for this. True, > it can be done with udev, but that's no reason not to move forward. > > I say Janne should continue on and convert the rest of the drivers... Is > anybody > opposed? > > This is a good idea. Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Doubt about the file: dvb-usb-dvb.c
Em Qui, 2007-08-02 às 09:39 +0800, lwtbenben escreveu: > >a) create a newer dir with your driver: > > /linux/drivers/media/dvb/mydriver > >b) Under /linux/drivers/media/dvb/mydriver: > > create a Kconfig and a Makefile > > You may use another Kconfig/Makefile as example (for example, > pluto2) > >c) Add your driver directory at /linux/drivers/media/dvb/Makefile: > > obj-y := dvb-core/ frontends/ ttpci/ ttusb-dec/ ttusb-budget/ >b2c2/ > bt8xx/ cinergyT2/ dvb-usb/ pluto2/ mydriver/ > >d) Add a source line for your driver > at /linux/drivers/media/dvb/Kconfig: > > source "drivers/media/dvb/mydriver/Kconfig" > >After that, you will be able to use v4l-dvb makefile to compile your > >driver. With > > make help > >you'll see some useful syntax that may help your development. > > Dear Mauro: > I had my problem solved last week, thank you all the same for clear > answer. > And I compile my module in the 2.6.20-15 kernel. > Now I want to compile the module in v4l-dvb tree, I did it this way: > I put my usb adapter program named usb-adapter.c in > linux/drivers/media/dvb/dvb-usb, and I modified the Makefile and > Kconfig to add my usb adapter module; > I put my frontend program named my-frontend.c in > linux/drivers/media/dvb/frontend and I modified the Makefile and > Kconfig to add my frontend module; > But the v4l-dvb tree can't compile. > There is some problem with the script make_myconfig.pl. > Do you have any advice about this issue? It is very unlikely to have a bug on make_myconfig.pl for such a simple task. Probably, you didn't selected the newer module with "make menuconfig". One alternative to avoid needing to manually select, is to indicate the minimum kernel version that the module requires. This is done via /v4/versions.txt file. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
Janne Grunau wrote:
> Hi,
>
> Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
> result in deterministic dvb adapter numbers.
>
> V4L drivers have the {radio|vbi|video}_nr module options to allocate
> static minor numbers per driver.
> Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
> problems with device unplugging and repluging each driver holds
> a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
> options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
> reversed allocation of adapter numbers.
> With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
> are already in use it will allocate the lowest free adapter number.
>
> Besides following changes in dvb-core and dvb-usb core the patch adds to
> all drivers
>
> +static int adapter_nr[] = {[0 ... (DVB_MAX_ADAPTERS - 1)] = DVB_UNSET };
> +module_param_array(adapter_nr, int, NULL, 0444);
> +MODULE_PARM_DESC(adapter_nr,"DVB adapter numbers");
>
> and modifies the dvb_register_adapter call. Full patch is attached as
> compressed file.
>
> With the exception of dvb-usb I have just added the paramter to the module
> with the dvb_register_adapter() call. budget-core and videobuf-dvb are
> affected for example. I'll push the option to the driver which uses these
> modules after we reached consent on the approach.
>
> Janne
I like this a lot -- In fact, I think I love it. I don't have anything negative
to say about this at all. I've always wanted a module option for this. True,
it can be done with udev, but that's no reason not to move forward.
I say Janne should continue on and convert the rest of the drivers... Is anybody
opposed?
Cheers,
Mike
--
Michael Krufky
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Wiki questions ... Hauppauge NOVA-T-500 and others
On Fri, 2007-08-03 at 10:18 -0400, CityK wrote: > (and thanks for the good work in the wiki) Just a tiny bit of work in return for the huge amount of work given by the devs. nico ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] TwinHan Magicbox VP7041 does not find any channels
Hej all, I'm new to this list and subscribed because I am trying to bring my TwinHan MagicBox VP7041 USB to work and I'm having troubles... But first let me say thank you to everybody spending his ressource to this project!! Here is my case: I try to make kaffeine or xine working with my DVB-T USB device on Debian Etch. Before I switched finally to Linux some days ago, I had a Windows XP running on another partition with the TwinHan-Software running satisfying. OK, there were some drop-outs, but the quality was OK and the channel scanning worked completely. I write this to document the hardware and the field intesity are OK. I installed dvb-utils and kaffeine, downloaded the firmware and copied it to /lib/firmware. The box is recongnized an the drivers are loaded: from syslog: Aug 2 20:17:00 localhost kernel: usb 1-2: new full speed USB device using uhci_hcd and address 7 Aug 2 20:17:00 localhost kernel: usb 1-2: configuration #1 chosen from 1 choiceAug 2 20:17:00 localhost kernel: dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. Aug 2 20:17:00 localhost kernel: dvb-usb: will use the device's hardware PID filter (table count: 16). Aug 2 20:17:00 localhost kernel: DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device). nl-lt-boris:~# lsusb Bus 002 Device 001: ID : Bus 001 Device 002: ID 1822:3202 Twinhan VisionDTV USB-Ter/HAMA USB DVB-T device warm Bus 001 Device 001: ID : No I try to scan for channels: [EMAIL PROTECTED]:~$ scan /usr/share/doc/dvb-utils/examples/scan/dvb-t/de-Kiel > channels.conf scanning /usr/share/doc/dvb-utils/examples/scan/dvb-t/de-Kiel using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 47400 0 2 9 1 1 3 0 initial transponder 58600 0 2 9 1 1 3 0 initial transponder 61800 0 2 9 1 1 3 0 initial transponder 66600 0 2 9 1 1 3 0 initial transponder 68200 0 2 9 1 1 3 0 initial transponder 76200 0 2 9 1 1 3 0 >>> >>> tune to: 47400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: >>> tuning failed!!! [SNIP - last message repeated a lot of times] ERROR: initial tuning failed dumping lists (0 services) Done. Also, dvdsnoop does not give out anything: nl-lt-boris:~# dvbsnoop -s pidscan dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ - Transponder PID-Scan... - So what can I do? I'm thankful for every hint! Boris ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Merging hvr3000 into main branch
And there we have it -- straight from the horse's mouth! Thanks for the status info Steve. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Merging hvr3000 into main branch
CityK wrote: > Emilio Castellano wrote: > >> I've been using steve's branch for hauppauge hvr3000 for a while.I'd >> like to know if somebody >> knows when it'll be commited steve's branch with dvb-s support to the >> main branch. >> >> > > As I believe that the hvr-3000 is fairly similar (except S2?) to the > hvr-4000, some recent insight from Steve may also explain the situation > for your device: > > http://www.linuxtv.org/pipermail/linux-dvb/2007-July/019432.html > The hvr3000 tree takes a very different approach to implementation vs the hvr4000. The HVR3000 adds support to the saa and cx88 tree's for multiple exclusive frontends on a single bus, enabling applications to open either a DVB-T or DVB-S frontend. It's proof of concept code. I asked for feedback very early on the new mechanism and the general consensus was positive. However, the tree contains changes to the DVB frontend framework and should be reviewed more closely prior to any updates/rework/merge activity. Given the current hybrid tuner project, it would be wise to leave the HVR3000 and HVR4000 tree's as-is. These product use hybrid tuners FMD1216 and will benefit from the tuner refactoring projects. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Merging hvr3000 into main branch
Emilio Castellano wrote: > I've been using steve's branch for hauppauge hvr3000 for a while.I'd like > to know if somebody > knows when it'll be commited steve's branch with dvb-s support to the > main branch. > As I believe that the hvr-3000 is fairly similar (except S2?) to the hvr-4000, some recent insight from Steve may also explain the situation for your device: http://www.linuxtv.org/pipermail/linux-dvb/2007-July/019432.html ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Wiki questions ... Hauppauge NOVA-T-500 and others
CityK wrote: > Cheers (and thanks for the good work in the wiki) And to you too Darren! Good stuff. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Wiki questions ... Hauppauge NOVA-T-500 and others
Nicolas Will wrote: > what version of the page are you looking at ? I had jotted a few notes down the other day and just got a chance to address these questions...I only glanced at the page today > On Fri, 2007-08-03 at 08:57 -0400, CityK wrote: > >> 1) Firmware listed looks to be the old (buggy) one ... can someone >> correct please >> > > this has been corrected yesterday ... > excellent >> 2) What is the "Bristol" reference ? . > this is apparently the code name to the engineering design. It is all > over the driver's code. > > It could probably be safely dropped from the wiki page, it must only > concern the coders. > No -- its an interesting tidbit and the wiki pages are for all (end users ans coders alike). My only concern was whether that bit was relevant to the device or not. As it is, it can certainly stay. >> 3) Does this card support the "diversity" feature ... >> > > > No. > > The PCI card that supports the diversity feature is NOT supported, and > this has a full section dedicated to it. Now that was a bit of a bonehead on my part given that I set up that section (based on the info you and others have provided). >> how about other >> devices like >> - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-Stick >> - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-TD-Stick >> >> IIRC, Patrick mention something about the diversity feature not set in >> the Linux driver yet, but that the dual mode works. But to which >> devices >> does this apply. >> > > I'll let others answer that. I'm selfishly focusing on the T-500. No problem. I'm not familiar with the devices ... [nor do I really want to become more familiar with them given the closest DVB-T transmission to me is likely some four and a half thousand KM away :D ] ... hence, I'm hoping to prompt those who ARE familiar (and know to which devices Patrick was referring) can add the appropriate info. Cheers (and thanks for the good work in the wiki) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Help with writing a DVB driver
Hello Andreas On 02/08/07, Thomas Gambier <[EMAIL PROTECTED]> wrote: > > > > On 02/08/07, Andreas Oberritter <[EMAIL PROTECTED]> wrote: > > > > Hello Thomas, > > > > There is another open source driver implementing the audio and video > > decoder API: > > > > http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/dvb/drivers/media/dvb/dbox2/Attic/dbox2_avia_av_napi.c?rev=1.1.2.1&only_with_tag=driver_2_6_branch&view=auto > > > > > Ok, thank you very much! I'll check this link tomorrow (for now, I'm going > to bed...) and give you a feedback... > I checked the link and it's great, I've understood that I just have to use the dvb_device structure for my video decoder. And then, I register it like another dvb device. I keep going on with this driver. Maybe I'll ask some more questions... Thanks -- Thomas Gambier ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Wiki questions ... Hauppauge NOVA-T-500 and others
On Fri, 2007-08-03 at 08:57 -0400, CityK wrote: > 1) Firmware listed looks to be the old (buggy) one ... can someone > correct please this has been corrected yesterday, http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500#Firmware pointing to http://www.wi-bw.tfh-wildau.de/~pboettch/home/linux-dvb-firmware/dvb-usb-dib0700-03-pre1.fw > > 2) What is the "Bristol" reference ? ... I changed it on the wiki > page > to read that it is a reference board design (just a guess), but I'm > not > sure if that's right or where this "Bristol" bit is even coming from. this is apparently the code name to the engineering design. It is all over the driver's code. It could probably be safely dropped from the wiki page, it must only concern the coders. > > 3) Does this card support the "diversity" feature ... No. The PCI card that supports the diversity feature is NOT supported, and this has a full section dedicated to it. http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500#WinTV-NOVA-TD-500 what version of the page are you looking at ? > how about other > devices like > - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-Stick > - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-TD-Stick > > IIRC, Patrick mention something about the diversity feature not set in > the Linux driver yet, but that the dual mode works. But to which > devices > does this apply. I'll let others answer that. I'm selfishly focusing on the T-500. :o) Nico ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Wiki questions ... Hauppauge NOVA-T-500 and others
1) Firmware listed looks to be the old (buggy) one ... can someone correct please 2) What is the "Bristol" reference ? ... I changed it on the wiki page to read that it is a reference board design (just a guess), but I'm not sure if that's right or where this "Bristol" bit is even coming from. 3) Does this card support the "diversity" feature ... how about other devices like - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-Stick - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-TD-Stick IIRC, Patrick mention something about the diversity feature not set in the Linux driver yet, but that the dual mode works. But to which devices does this apply. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] feedback, nova-t 500
On Fri, 2007-08-03 at 08:47 +0200, Henrik Beckman wrote: > Haven´t tried that. > But I will update to the latest code and firmware next week and do a > check if the reception patch is still needed > and general functionality test. I am trying it. It patches fine, it compiles fine, and the module load messages indicate functionality. I also get better signal levels when tuning. I have not seen much difference in practical terms, though, but at least it doesn't look like it is breaking major things. I am still leaving the warning on the wiki page, though, as a sample of very few reports is not too good. There is also the issue of the need of a true EEPROM parser that would make this patches functionality more reliable. It doesn't exist yet, and this patch probably does its thing in a cow-boy-ish way, hence its non inclusion in the main tree. Nico ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
