Perceval Anichini wrote: > Hello ! > >As fas as i understand, the DST_CA driver works as described below : > - The driver is fed with EN 50221 messages. > - The driver translates these messages to DST proprietary > command > - The DST process the command and reply to the driver in a > proprietary format (!@*#!@^$!&*!($@!#@!#@!) > > You can take a look at how it is implemented in http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel/linux/Documentation/dvb/ci.txt?rev=1.4&view=markup > - The driver return the 'data' as is. > >It seems to me that it would be interesting to return replies in EN >50221 format. Below is a patch that does it for the 'Application Info' >reply, as described page 28 of the standard. I will send patches for >other replies if i can retrieve some documentations about the DST >part of the card. > > > You mean the object return values, dont you ? Hmm.. if you would like that to be included since it would break dst_util, it would be nice if you would include a patch for the same for http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-apps/util/dst-utils/ But the problem there is calculating the length of the messages. Right now it is a blind read. In exact terms need to fix that first, to do this, since length of message. > Moreover, I don't understand the ca_msg structure. > - Why is the msg field only 256 bytes long ? If I understood >the standard, an EN 50221 message can be up to 65536 + 6 (3 bytes for >tag, up to 3 bytes for field_length, and 65536 bytes of payload.) Is it >a kernel related limitation (?) > > If you are looking at EN50221 implementation, Refer EN50221 Section 8.3.2 as well as R206, page 34 CA_PMT and friends > - I do not understand the index and type member. They seems to >be always set to zero by the driver. > > Refer Linux DVB-API. The implementation of the HLCI API worked from start to leave out length from the header to avoid confusion, thus having length encoded as ASN.1 only. > - I do think I understand the length part :) But the driver >set it to 0 too... > >For information, we are using a Technisat Skystar 1/CI, with an ASTON >CAM PRO Viaccess (firmware 2.0100) . > > I don't know whether this is good news or not. The list of supported CAM's are like this .. maybe it might be of some help. This is regarding the state of the DST, Regarding the Skystar-1, i have not much of an idea. This might probably be applicable for you. Crypto Works 1.0 OK Cryptoworks 12011 N/A???CAM? Magic 1.1 OK 76.5 NG Dragon I & II 2.05, 2.06 N/A???CAM? PentaCrypt 1.05 OK Irdeto 2.09 OK 110.5 OK Irdeto 1.06 N/A???CAM? Free CAM2-018 ?? OK AstonCrypt 1.03 OK Viaccess 1.0 V481 OK 76.5 OK Viaccess 1.0 V483 OK 76.5 OK AlphaCrypt 1.0 OK Aston I 1.05 OK AstonII ?? NG SECA I & II 1.05 N/A???CAM? Nagravision ?? OK Free-X-TV 2.26 OK 95 OK Free-X-TV 2.0 N/A???CAM? Module 0.78 OK Zeta Cam ?? OK 76.5/95 OK Conax 4.00e OK Conax 4.0 N/A???CAM? BataCrypt 1.0 N/A???CAM? ?????Pass(????????) P/Pass(?????????) NG(??????) N/A(??????????) >- The second patch included corrects the asn_1_decode function. >Patches apply in following order : > - patch-1-dst_ca-application-info-en50221 > - patch-2-dst_ca-asn_1_decode > >Thanks a lot. > >Perceval. > > >------------------------------------------------------------------------ > >--- dvb-kernel.orig/linux/drivers/media/dvb/bt8xx/dst_ca.c 2005-09-02 21:41:47.000000000 +0200 >+++ dvb-kernel/linux/drivers/media/dvb/bt8xx/dst_ca.c 2005-09-06 10:22:32.000000000 +0200 >@@ -163,6 +163,27 @@ > (state->messages[10] << 8) | state->messages[11], __FUNCTION__, (char *)(&state->messages[12])); > dprintk(verbose, DST_CA_INFO, 1, " =================================================================================================="); > >+ // Now, we need to build the correct EN 50221 >+ // First, replace weird DST reply by EN 50221 Application Info SPDU (p 28) >+ state->messages[0] = 0x9f; >+ state->messages[1] = 0x80; >+ state->messages[2] = 0x21; >+ >+ // Second, compute field_length : >+ // FIXME -> might be coded on more than 1 byte. > > >+ // FIXME -> Information already coded in state->messages[5] (???) > > >+ state->messages[3] = 6 + strlen (state->messages + 12); > > See my comment on this issue. >+ >+ // Third, fill application_type. >+ state->messages[4] = state->messages[7]; >+ >+ // Third, move application_manufacturer and manufacturer_code to the correct place. >+ memmove (state->messages + 5, state->messages + 8, 2 * sizeof (u16)); >+ >+ // And last, format correctly the menu_string_length >+ state->messages[9] = strlen (state->messages + 12); >+ memmove (state->messages + 10, state->messages + 12, state->messages[9]); >+ > return 0; > } > > >--- dvb-kernel.orig/linux/drivers/media/dvb/bt8xx/dst_ca.c 2005-09-02 21:41:47.000000000 +0200 >+++ dvb-kernel/linux/drivers/media/dvb/bt8xx/dst_ca.c 2005-09-06 10:22:32.000000000 +0200 >@@ -329,7 +350,8 @@ > } else { > word_count = length_field & 0x7f; > for (count = 0; count < word_count; count++) { >- length = (length | asn_1_array[count + 1]) << 8; >+ length = length << 8; >+ length += asn_1_array[count + 1]; > dprintk(verbose, DST_CA_DEBUG, 1, " Length=[%04x]", length); > } > } > > > > I will check this in, would you mind the signed-off-by: line ? Thanks, Manu
