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

[Thierry Merle]

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,	0xfe01eb04,	KEY_POWER },
	{ 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