> -----Original Message----- > From: Sigmund Augdal Helberg [mailto:sigmund@xxxxxxx] > Sent: den 17 januari 2006 12:27 > To: Henrik Sjoberg > Cc: linux-dvb@xxxxxxxxxxx > Subject: Re: [linux-dvb] [PATCH] dst_ca: ca_info and application_info > > On Tue, 2006-01-17 at 10:09 +0100, Henrik Sjoberg wrote: > > > On Mon, 2006-01-09 at 14:33 +0100, Henrik Sjoberg wrote: > > >> Hi, > > >> Today, application info can be enquired from the dst_ca ca using the > > ioctl > > >> CA_APP_INFO_ENQUIRY. However, the answer which is returned is the raw > > data > > >> of the answer from the HW and not formatted as described in EN-50221. > > (Which is probably why there is a "only for debugging"-comment in the > code). > > >> I have made patch which > > >> 1. Restructures the answer from CA_APP_INFO_ENQUIRY to conform with > > application_info (EN50221:1997, p.28). > > >> 2. Adds support for CA Info Enquiry, conforming to EN50221:1997, p.29. > > Since this will break dst_test -a, a patch is also needed for dvb-apps > to > > >> correct dst_test for application info and add support for ca info. It > > would be great if anyone more familiar with the specs. could take a look > > at it and see if it looks ok. It would also be good to have some testing > > from some Twinhan CI-card users as well. > > > I'm really happy to see someone pick up on the twinhan ci code. As > soon > > as I find some time I will try this out and proof-read the code > > > somewhat. And if it turns out to be correct I'll update vlc to handle > > the correct app info, and use the ca info as well. > > > > > > Where did you get the magic command? And do you have commands for > > remaining en50221 objects? I'm particularly interrested in the mmi parts. > > > > > > Regards, > > > Sigmund > > > > I have implemented a rudimentary HLCI support for mythtv and the > structure > > there needed the ca_info to be implemented in the driver. > All my tests shows that the ca_info isn't actually needed for hlci. > ca_info is normally used to filter away ca descriptors not supported by > the cam, but all evidence shows that the twinhan firmware does this for > us. Anyway I can imagine the code looking prettier when ca_info is > known. > > > > By 'magic command' I assume you mean command to the hardware. I > discovered > > that all information that was needed for the ca_info was present in the > > request for the slots_caps. > >From your patch: > + static u8 slot_command[8] = {0x07, 0x40, 0x00, 0x00, 0x02, 0x00, > 0x00, 0xff}; > > This is different from the slot_caps query which is: > static u8 slot_command[8] = {0x07, 0x40, 0x02, 0x00, 0x02, 0x00, > 0x00, 0xff}; Ah, yes. I was interested in what the different commands to the hw was used for and was disassembling the windows driver. I noticed that the caps command in those drivers differed on the third byte and I tried it out. It seemed like it didn't change anything for me. As I said, I'm lacking documentation of the hardware. > So I imagined you had some kind of listing of usable commands, that you > used to find this one, and that this list included the needed parts for > mmi. If you don't have such a list I'll have to wait for Manu. I noticed some mmi commands as well when disassembling. However, I don't know exactly what they do and how the answer is interpreted. > Btw: Have you experienced i2c errors in the logs ("trying to recover > from previous errors" and "RDC 8820 RESET"), and if so, do descrambling > stop for you at these points? Not that I have noticed. I haven?t used the descrambling for a longer time on channels. I have only tried it out and tested that it works to switch between channels and so. Regards, Henrik > > Regards, > > Sigmund > > > > > For the mmi commands I can not help you much for now on how to access it > > in the hardware. Maybe Manu can be of assistance? > > > > Regards, > > Henrik > >
