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 listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
