[linux-dvb] Testers wanted for alternative version of Terratec Cinergy T2 driver

Ingo Peukes admin at ipnetwork.de
Thu May 8 22:47:06 CEST 2008


count me as a tester for the new driver cause I can't use the old one.
As I'm primary a system administrator and not a programmer I just can 
give informations from a users view.

I use the driver on my Linkstation Live which I'm going to turn into a
VDR using mythtv, and for now I can tell it compiles on this NAS with 
kernel and the v4l-dvb sources found here:

I use this cause I also have Pinnacle PCTV200e which is not supported by
the official sources. The PCTV card is also the reason why I cannot use 
the old/original driver cause somehow neither device is usable when 
both drivers are loaded. I think this comes because they both have a 
Zarlink MT352 and it seems that the modules mt352 and cinergyT2
can't work together. This problem does not exist with your driver.
So I'm happy you go for a new cinergyT2 driver :)

Well, as I said it compiles and works with the above kernel and v4l-dvb
but w_scan finds no channels with this module most of the time. In 5 
runs it found 4 channels on one multiplex.
I doubt it's the antenna although it's the stock one but if I use the
cinergyT2 on my desktop pc with the original module of kernel 
w_scan finds all available channels all the time with the same antenna 
in the same place. I will try a better antenna tomorrow to see if I can 
use it somewhat productive in mythtv...

Ingo Peukes

Thierry Merle wrote:
> Tomi Orava a écrit :
>> Hi,
>>> Well, I see some issues after taking a closer look at your driver:
>>> 1- checkpatch.pl raises errors: 90 errors, 53 warnings, 995 lines checked
>>> 2- there is a compilation error (I applied the patch on the latest
>>> v4l-dvb tree):
>>> cinergyT2-core.c: In function 'cinergyt2_usb_probe':
>>> cinergyT2-core.c:138: error: too few arguments to function
>>> 'dvb_usb_device_init'
>>> 3- you should replace the existing driver, not proposing a different
>>> driver. I mean, patch directly
>>> linux/drivers/media/dvb/cinergyT2/cinergyT2.c.
>> Ok, these are easy to fix.
>>> Furthermore, I have some questions:
>>> - is there a way to use the dvb-usb-remote module? This in order to get
>>> rid of cinergyT2-remote.c
>> No, due to the fact that the dvb-usb.h defines a struct which is too
>> limited for the Cinergy T2 remote controller handling. If you compare
>> the original struct dvb_usb_rc_key to the modified one:
>> Original:
>> struct dvb_usb_rc_key {
>>         u8 custom,data; <--------------------
>>         u32 event;
>> };
>> Cinergy T2 send U32 remote controller:
>> struct cinergyt2_rc_key {
>> 	u32 custom; <--------------
>> 	u32 data;   <--------------
>> 	u32 event;
>> };
>> Obviously I could get rid of the whole cinergyT2-remote.c file
>> if the dvb-usb defined struct could be widened.
> Indeed, but in the current structure I am not sure that all the bits of the u32 data is useful.
> For example:
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xfd02eb04,	KEY_1 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xfc03eb04,	KEY_2 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xfb04eb04,	KEY_3 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xfa05eb04,	KEY_4 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xf906eb04,	KEY_5 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xf807eb04,	KEY_6 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xf708eb04,	KEY_7 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xf609eb04,	KEY_8 },
> 	{ CINERGYT2_RC_EVENT_TYPE_NEC,	0xf50aeb04,	KEY_9 },
> I see for example that in the u32 0xfe01eb04, first and second bytes are linked (0xfe + 0x01 = 0xff)
> It works with all others: 0xfd02eb04 -> 0xfd + 0x02 = 0xff, ...
> Furthermore the last 2 bytes are constant (0xeb04).
> So the sole significant byte is the second: 0x01, 0x02, ...
> I will try to do something around that.
>>> - so, renaming cinergyT2-core.c to cinergyT2.c would be correct?
>> Hmm, if I remember correctly there was some sort of clash with the filenames
>> and the actual compiled driver.
> In fact if you remove the old driver (by resolving the issue #3), I suggested to name the cinergyT2-core.c cinergyT2.c but there is no obligation. 
>>> - stream buffer count was set to 32 in the old driver and you set it to
>>> 5, why this change? It works perfectly with 5 and consumes less memory
>>> so if this is the reason I fully agree!
>> As the old existing driver is handling the communication differently
>> also the buffer count values are different. When I began writing the
>> new version of the CinergyT2 driver I did some trials and based on the
>> helpful comments & test results the value of 5 has been there.
> OK
>>> I think the best way is to rework your patch and fix these issues; I can
>>> help you if you want.
>>> Then I will commit that in a particular tree and ask for pushing it to
>>> the official tree.
>> Sure, I'll fix the reported errors and get back to you.
> Thanks
>> Regards,
>> Tomi Orava
> Cheers,
> Thierry
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

More information about the linux-dvb mailing list