Hello, 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 aVDR using mythtv, and for now I can tell it compiles on this NAS with kernel 2.6.25.1 and the v4l-dvb sources found here:http://ubuntuforums.org/showthread.php?t=511676&page=8 I use this cause I also have Pinnacle PCTV200e which is not supported bythe 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 cinergyT2can'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-dvbbut 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 thecinergyT2 on my desktop pc with the original module of kernel 2.6.25.1 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... RegardsIngo 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, 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>> _______________________________________________> linux-dvb mailing list> linux-dvb@xxxxxxxxxxx> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb _______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
