IR mce remote
Hi, I'm having this trouble with a MCE USB remote from SMK Manufacturing (USB ID 0609:0334). Kernel version is 3.1.9 on opensuse 12.1 32bit. The remote itself is a Sony RM-MCE20E (RC6 compatible). But problems also arise with the Hauppauge I've got. Whenever I push the same button rapidly, it will trigger itself more than 2 times. Currently, this is happening with the arrows under xbmc (it will scroll a lot more than what I pressed on the buttons). It also happens under the small tool 'input-events' where I can get results like 21:51:55.631200: EV_MSC MSC_SCAN -2146499551 21:51:55.631205: EV_KEY KEY_RIGHT pressed 21:51:55.631205: EV_SYN code=0 value=0 ^[[C21:51:55.738203: EV_MSC MSC_SCAN -2146499551 21:51:55.738204: EV_SYN code=0 value=0 21:51:55.844201: EV_MSC MSC_SCAN -2146499551 21:51:55.844202: EV_SYN code=0 value=0 21:51:55.951199: EV_MSC MSC_SCAN -2146499551 21:51:55.951201: EV_SYN code=0 value=0 21:51:56.057202: EV_MSC MSC_SCAN -2146499551 21:51:56.057203: EV_SYN code=0 value=0 ^[[C21:51:56.163202: EV_MSC MSC_SCAN -2146499551 21:51:56.163203: EV_SYN code=0 value=0 ^[[C^[[C^[[C^[[C21:51:56.270203: EV_MSC MSC_SCAN -2146499551 21:51:56.270205: EV_SYN code=0 value=0 ^[[C^[[C^[[C21:51:56.376204: EV_MSC MSC_SCAN -2146499551 21:51:56.376206: EV_SYN code=0 value=0 ^[[C^[[C^[[C^[[C21:51:56.482206: EV_MSC MSC_SCAN -2146499551 21:51:56.482207: EV_SYN code=0 value=0 ^[[C^[[C^[[C^[[C21:51:56.615205: EV_MSC MSC_SCAN -2146499551 21:51:56.615207: EV_SYN code=0 value=0 ^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C21:51:56.864515: EV_KEY KEY_RIGHT released 21:51:56.864516: EV_SYN code=0 value=0 I tried increasing the delay/period value, but it does not help ir-keytable output ... Protocols changed to RC-6 Repeat delay = 1000 ms, repeat period = 1000 ms Changed Repeat delay to 2000 ms and repeat period to 5000 ms It seems like the events are being queued somewhere and released at once and in full (without any being discarded to respect the delay/period conditions). Any help would be welcome. Thx -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV ported to Windows
Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. Yes indeed, it is a pity but it seems this work is in violation of the GPL. -- This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. -- [http://www.gnu.org/philosophy/why-not-lgpl.html] [http://www.gnu.org/copyleft/gpl.html] -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [DVB] CXD2099 - Question about the CAM clock
I managed to find a series of values that are working correctly for MCLKI: MCLKI = 0x5554 - i * 0x0c In my case I can go down to 0x5338 before having TS errors. From CXD2099 specs -- It is a requirement for the frequency of MCLKI to be set higher than the input data rate. ie 8 times TICLK. If this condition is not met then the internal buffer will overflow and the register TSIN_FIFO_OVFL is set to 1. This register should be read at regular intervals to ensure reliable operation. -- Watch out that you're not slowly overflowing the internal buffer if MCLKI is not fast enough... Are you working with the ddbridge ? -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DVB] CXD2099 - Question about the CAM clock
Dear Oliver, Ive done some tests with the CAM reader from Digital Devices based on Sony CXD2099 chip and I noticed some issues with some CAM: * SMIT CAM: working fine * ASTON CAM : working fine, except that it's crashing quite regularly * NEOTION CAM : no stream going out but access to the CAM menu is ok When looking at the CXD2099 driver code, I noticed the CAM clock (fMCLKI) is fixed at 9MHz using the 27MHz onboard oscillator and using the integer divider set to 3 (as MCLKI_FREQ=2). I was wondering if some CAM were not able to work correctly at such high clock frequency. So, I've tried to enable the NCO (numeric controlled oscillator) in order to setup a lower frequency for the CAM clock, but I wasn't successful, it's looking like the frequency must be around the 9MHz or I can't get any stream. Do you know a way to decrease this CAM clock frequency to do some testing? Best regards, Sebastien. Weird that the frequency would pose a problem for those CAMs. The CI spec [1] explains that the minimum byte transfer clock period must be 111ns. This gives us a frequency of ~9MHz. Anyway, wouldn't it be wiser to base MCLKI on TICLK ? -- Issa [1] http://www.dvb.org/technology/standards/En50221.V1.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/16] ngene: Update for latest cxd2099
From: Oliver Endriss o.endr...@gmx.de
Modifications for latest cxd2099.
Signed-off-by: Oliver Endriss o.endr...@gmx.de
---
drivers/media/dvb/ngene/ngene-core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index fa4b3eb..df0f0bd 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1582,11 +1582,18 @@ static int init_channels(struct ngene *dev)
return 0;
}
+static struct cxd2099_cfg cxd_cfg = {
+ .bitrate = 62000,
bitrate's never used anywhere (yet ?), why keeping it ?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] cxd2099: Update to latest version
On 03/07/2011 19:00, Oliver Endriss wrote:
@@ -284,53 +313,84 @@ static int init(struct cxd *ci)
CHK_ERROR(write_reg(ci, 0x08, 0x28));
CHK_ERROR(write_reg(ci, 0x14, 0x20));
- CHK_ERROR(write_reg(ci, 0x09, 0x4D)); /* Input Mode C, BYPass
Serial, TIVAL = low, MSB */
+ /* CHK_ERROR(write_reg(ci, 0x09, 0x4D));*/ /* Input Mode C,
BYPass Serial, TIVAL = low, MSB */
CHK_ERROR(write_reg(ci, 0x0A, 0xA7)); /* TOSTRT = 8, Mode B
(gated clock), falling Edge, Serial, POL=HIGH, MSB */
- /* Sync detector */
CHK_ERROR(write_reg(ci, 0x0B, 0x33));
CHK_ERROR(write_reg(ci, 0x0C, 0x33));
CHK_ERROR(write_regm(ci, 0x14, 0x00, 0x0F));
CHK_ERROR(write_reg(ci, 0x15, ci-clk_reg_b));
CHK_ERROR(write_regm(ci, 0x16, 0x00, 0x0F));
- CHK_ERROR(write_reg(ci, 0x17, ci-clk_reg_f));
+ CHK_ERROR(write_reg(ci, 0x17,ci-clk_reg_f));
- CHK_ERROR(write_reg(ci, 0x20, 0x28)); /* Integer Divider,
Falling Edge, Internal Sync, */
- CHK_ERROR(write_reg(ci, 0x21, 0x00)); /* MCLKI = TICLK/8 */
- CHK_ERROR(write_reg(ci, 0x22, 0x07)); /* MCLKI = TICLK/8 */
+ if (ci-cfg.clock_mode) {
+ if (ci-cfg.polarity) {
+ CHK_ERROR(write_reg(ci, 0x09, 0x6f));
+ } else {
+ CHK_ERROR(write_reg(ci, 0x09, 0x6d));
+ }
+ CHK_ERROR(write_reg(ci, 0x20, 0x68));
+ CHK_ERROR(write_reg(ci, 0x21, 0x00));
+ CHK_ERROR(write_reg(ci, 0x22, 0x02));
When clock_mode = 1, you set MKCLI to 9MHz. Comments in this code would
be really nice. Used by ddbrige it seems.
+ } else {
+ if (ci-cfg.polarity) {
+ CHK_ERROR(write_reg(ci, 0x09, 0x4f));
+ } else {
+ CHK_ERROR(write_reg(ci, 0x09, 0x4d));
+ }
+ CHK_ERROR(write_reg(ci, 0x20, 0x28));
+ CHK_ERROR(write_reg(ci, 0x21, 0x00));
+ CHK_ERROR(write_reg(ci, 0x22, 0x07));
+ }
When clock_mode = 0, input ts is in serial mode C, MCLKI = TICLK / 8 ;
why not set register 0x20 to 0x8 only ? Also, no need to set 0x21 nor
0x22 which are only for serial input mode D. And only used by ngene it
seems. Is TICLK equal to the bitrate variable (6200) ? If yes, then
MCLKI can only reach a value of ~7,8MHz, which is not the maximum speed
of CAMs. Is this on purpose ? Ngene chip limitation ?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DVB] Possible regression in stb6100 module for DVBS2 transponders
On 01/07/2011 10:44, Sébastien RAILLARD (COEXSI) wrote: Dear Manu, I think there is a regression in your patch from December 2010 regarding the stb6100 module. With the latest version of stb6100 published in media_build git branch, we can't tune the TT-S2-3200 on some DVBS2 transponders like Hotbird 13E 11681-H-27500 or Hotbird 13E 12692-H-27500. After reverting to the previous stb6100_set_frequency function, it's working fine. So, there is maybe in issue in the last December code refactoring. Reference of the patch: [media] stb6100: Improve tuner performance http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/dvb/frontend s/stb6100.c;h=bc1a8af4f6e105181670ee33ebe111f98425e0ff;hb=HEAD See below for the code removed from the stb6100.c file (the stb6100_set_frequency function) and the code added (the previous stb6100_set_frequency function and the stb6100_write_regs function). Best regards, Sebastien. Reported back in may [http://www.mail-archive.com/linux-media@vger.kernel.org/msg31334.html] -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
I hope this driver will be included if it can be useful for some and if it follows the GPL rules. But really, +1 to Sebastien's comment - this project is a frustrating one it seems. And at the point where I am, I would rather pay for a working driver for a S2 + CI card, instead of trying to debug existing drivers for which the maintainers are virtually non existent. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH] ngene: blocking and nonblocking io for sec0
Haven't fully understood the usage of wake_event_interruptible, now I have read
its description. Sorry for the lame patch.
Please find a fixed version below.
Patch allows for blocking or nonblocking io on the ngene sec0 device.
It also enforces one reader and one writer at a time.
Signed-off-by: Issa Gorissen flo...@usa.net
--
--- a/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-05-10 19:11:21.0
+0200
+++ b/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-06-21 23:46:09.0
+0200
@@ -53,15 +53,30 @@ static ssize_t ts_write(struct file *fil
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- if (wait_event_interruptible(dev-tsout_rbuf.queue,
-dvb_ringbuffer_free
-(dev-tsout_rbuf) = count) 0)
+ if (!count)
return 0;
- dvb_ringbuffer_write(dev-tsout_rbuf, buf, count);
+ if (nonblock) {
+ avail = dvb_ringbuffer_free(dev-tsout_rbuf);
+ if (!avail)
+ return -EAGAIN;
+ if (count avail)
+ avail = count;
+ } else {
+ if (wait_event_interruptible(dev-tsout_rbuf.queue,
+dvb_ringbuffer_free
+(dev-tsout_rbuf) = count) 0)
+ return -EINTR;
+
+ avail = count;
+ }
+
+ dvb_ringbuffer_write(dev-tsout_rbuf, buf, avail);
+ return avail;
- return count;
}
static ssize_t ts_read(struct file *file, char *buf,
@@ -70,22 +85,29 @@ static ssize_t ts_read(struct file *file
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
- int left, avail;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- left = count;
- while (left) {
- if (wait_event_interruptible(
- dev-tsin_rbuf.queue,
- dvb_ringbuffer_avail(dev-tsin_rbuf) 0) 0)
- return -EAGAIN;
+ if (!count)
+ return 0;
+
+ if (nonblock) {
avail = dvb_ringbuffer_avail(dev-tsin_rbuf);
- if (avail left)
- avail = left;
- dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
- left -= avail;
- buf += avail;
+ if (!avail)
+ return -EAGAIN;
+ if (avail count)
+ avail = count;
+ } else {
+ if (wait_event_interruptible(dev-tsin_rbuf.queue,
+dvb_ringbuffer_avail
+(dev-tsin_rbuf) = count) 0)
+ return -EINTR;
+
+ avail = count;
}
- return count;
+
+ dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
+ return avail;
}
static const struct file_operations ci_fops = {
@@ -98,9 +120,9 @@ static const struct file_operations ci_f
struct dvb_device ngene_dvbdev_ci = {
.priv= 0,
- .readers = -1,
- .writers = -1,
- .users = -1,
+ .readers = 1,
+ .writers = 1,
+ .users = 2,
.fops= ci_fops,
};
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
On 13/06/2011 00:30, Bart Coninckx wrote: Hi all, hope you can help me this one, because there's not a whole of info about similar problems to be found. I have a Technotrend S2-3200 with CI and on three different distros I get this dvb_ca adaptor 0: PC card did not respond :( in /var/log/messages. Hi Bart, I've got the same card running under OpenSuse 11.4 and Mythtv 0.24.1 I also have the same warning message, but somehow, when Mythtv grabs the device, the CAM will be reset successfully (at least, in my case). In the past, I solved this annoyance by adding a sleep in the CAM init code [1] relevant to the S2-3200 until I found out Mythtv does something about it. [1] drivers/media/dvb/dvb-core/dvb_ca_en50221.c in function dvb_ca_en50221_thread(void) add a sleep of 5 or 10 secs between the 1st dprintk and the main loop. Hope this helps, -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
On 14/06/2011 12:48, Bart Coninckx wrote: I will try your suggestion though. Off topic, but would you advice 11.4 in favor of 11.3? As a secondary route, I was thinking about using sasc-ng (softcamming, legal in this case) and the code seems not to want to compile on 11.4. Also 11.4 broke after updating the kernel. Except from the different kernel version, you can go for 11.3, as far as you're concerned only by TV related stuff. You might want to recompile the kernel with a newer version to get all the patches related to the S2 3200. Also, do not hesitate to try out different versions of the kernel if you stumble upon problem with the S2 3200; I had some trouble with it and some recent patches do not suit my setup (dish, cable length, diseqc switch, etc ...) For the sasc-ng matter, I did play with it last year but figured it is a time black hole when it does not work. I guess you have a legal subscription card. Then unless you like to play around, just drop softcams. And CAMs are not that expensive. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DVB] In research of chip's datasheets
On 20/05/2011 18:01, Sébastien RAILLARD (COEXSI) wrote: I'm in research of datasheets of the following chips: - tuner STV6110A from ST - dual demodulator STV0900B from ST - CI interface CXD2099AR from SONY Hi Sebastien, If you're targeting the ngene based cards, I think you will also need the spec for the ngene chip and my guess is that it has been programmed (not generic like the 3 other chips). So as Ralph is already in contact with digital devices, I wonder if you will get this information. For the cxd2099ar, talk to sony europe CXD2099_supporteu./sony/.com -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
On 19/05/11 23:01, Sébastien RAILLARD (COEXSI) wrote: Yes, of course, but I don't find information that can help me to provide the correct format. Is-there a documentation somewhere that explains how patches must be formatted to be correctly tracked? This should help [http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches] -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 11/05/2011 20:59, Oliver Endriss wrote: I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 CU Oliver Great! Will give it a try tonight and report. Thx, -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ngene: blocking and nonblocking io for sec0
Patch allows for blocking or nonblocking io on the ngene sec0 device.
It also enforces one reader and one writer at a time.
Signed-off-by: Issa Gorissen flo...@usa.net
--
--- a/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-05-10 19:11:21.0
+0200
+++ b/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-05-12 15:28:53.573185365
+0200
@@ -53,15 +53,29 @@ static ssize_t ts_write(struct file *fil
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- if (wait_event_interruptible(dev-tsout_rbuf.queue,
-dvb_ringbuffer_free
-(dev-tsout_rbuf) = count) 0)
+ if (!count)
return 0;
- dvb_ringbuffer_write(dev-tsout_rbuf, buf, count);
+ if (nonblock) {
+ avail = dvb_ringbuffer_avail(dev-tsout_rbuf);
+ if (!avail)
+ return -EAGAIN;
+ } else {
+ while (1) {
+ if (wait_event_interruptible(dev-tsout_rbuf.queue,
+dvb_ringbuffer_free
+(dev-tsout_rbuf) =
count) = 0)
+ break;
+ }
+ avail = count;
+ }
+
+ dvb_ringbuffer_write(dev-tsout_rbuf, buf, avail);
+ return avail;
- return count;
}
static ssize_t ts_read(struct file *file, char *buf,
@@ -70,22 +84,35 @@ static ssize_t ts_read(struct file *file
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
- int left, avail;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- left = count;
- while (left) {
- if (wait_event_interruptible(
- dev-tsin_rbuf.queue,
- dvb_ringbuffer_avail(dev-tsin_rbuf) 0) 0)
- return -EAGAIN;
+ if (!count)
+ return 0;
+
+ if (nonblock) {
avail = dvb_ringbuffer_avail(dev-tsin_rbuf);
- if (avail left)
- avail = left;
- dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
- left -= avail;
- buf += avail;
+ } else {
+ while (!avail) {
+ if (wait_event_interruptible(
+ dev-tsin_rbuf.queue,
+ dvb_ringbuffer_avail(dev-tsin_rbuf) 0)
0)
+ continue;
+
+ avail = dvb_ringbuffer_avail(dev-tsin_rbuf);
+ }
}
- return count;
+
+ if (avail count)
+ avail = count;
+ if (avail 0)
+ dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
+
+ if (!avail)
+ return -EAGAIN;
+ else
+ return avail;
+
}
static const struct file_operations ci_fops = {
@@ -98,9 +125,9 @@ static const struct file_operations ci_f
struct dvb_device ngene_dvbdev_ci = {
.priv= 0,
- .readers = -1,
- .writers = -1,
- .users = -1,
+ .readers = 1,
+ .writers = 1,
+ .users = 2,
.fops= ci_fops,
};
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB nGene CI : TS Discontinuities issues
On 11/05/11 15:12, Issa Gorissen wrote:
From: Ralph Metzler r...@metzlerbros.de
Issa Gorissen writes:
Could you please take a look at the cxd2099 issues ?
I have attached a version with my changes. I have tested a lot of
different settings with the help of the chip datasheet.
Scrambled programs are not handled correctly. I don't know if it is the
TICLK/MCLKI which is too high or something, or the sync detector ? Also,
as we have to set the TOCLK to max of 72MHz, there are way too much null
packets added. Is there a way to solve this ?
I do not have any cxd2099 issues.
I have a simple test program which includes a 32bit counter as payload
and can pump data through the CI with full speed and have no packet
loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
but also had no problems with this.
Please take care not to write data faster than it is read. Starting two
dds will not guarantee this. To be certain you could write a small
program which never writes more packets than input buffer size minus
the number of read packets (and minus the stuffing null packets on ngene).
Before blaming packet loss on the CI data path also please make
certain that you have no buffer overflows in the input part of
the sec device.
In the ngene driver you can e.g. add a printk in tsin_exchange():
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
...
} else
printk (buffer overflow \n);
Regards,
Ralph
Ralph,
Done some more tests, from by test tool, I found out that I have to skip
(rather often) bytes to find the sync one when reading from sec0. I
thought I only needed to do that at the start of the stream, not in the
middle; because I always read/write 188 bytes from it.
Could you share your test code ? I'm finding it difficult to interact
with this sec0 implementation.
Thx
--
Issa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dvb demux: isolating the pids related to a scrambled channel
Hi, To decramble a channel with a ngene based card, you either need to: 1) send the full ts to sec0; 2) send a filtered ts to sec0. The latter case shall permit the descrambling of 2 channels transmitted from 2 different ts/tuners. I'm interested in knowing how to do this: filter a ts so that I only keep the needed pids for the cam. Can anyone help ? Thx -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB nGene CI : TS Discontinuities issues
From: Ralph Metzler r...@metzlerbros.de
Issa Gorissen writes:
Could you please take a look at the cxd2099 issues ?
I have attached a version with my changes. I have tested a lot of
different settings with the help of the chip datasheet.
Scrambled programs are not handled correctly. I don't know if it is the
TICLK/MCLKI which is too high or something, or the sync detector ? Also,
as we have to set the TOCLK to max of 72MHz, there are way too much null
packets added. Is there a way to solve this ?
I do not have any cxd2099 issues.
I have a simple test program which includes a 32bit counter as payload
and can pump data through the CI with full speed and have no packet
loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
but also had no problems with this.
Please take care not to write data faster than it is read. Starting two
dds will not guarantee this. To be certain you could write a small
program which never writes more packets than input buffer size minus
the number of read packets (and minus the stuffing null packets on ngene).
Before blaming packet loss on the CI data path also please make
certain that you have no buffer overflows in the input part of
the sec device.
In the ngene driver you can e.g. add a printk in tsin_exchange():
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
...
} else
printk (buffer overflow \n);
Regards,
Ralph
Ralph,
Please find my testing tool for the decryption attached. The idea is to write
5 packets and read them back from the CAM.
My input is a raw ts captured with a gnutv I modified with a demux filter of
0x2000. Gnutv outputs at dvr and dvbloop reads from it, process via sec0 and
writes output to a file.
The channel I selected has been decrypted. Only problem is I have artifacts in
the image and the sound.
Do you have any idea of what I should improve from my test tool to fix that
issue ?
Thx,
--
Issa
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include signal.h
#include stdlib.h
#include stdio.h
#include unistd.h
#include time.h
static void signal_handler(int _signal);
static int quit_app = 0;
int main(int argc, char *argv[])
{
signal(SIGINT, signal_handler);
if (argc = 3)
exit(1);
int in_fd = open(argv[1], O_RDONLY);
int out_fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
int tsi_fd = open(argv[3], O_RDWR);
int rlen = 0;
int wlen = 0;
int rtsilen = 0;
int wtsilen = 0;
int BUFFY = 188 * 5;
unsigned char buf[BUFFY];
struct timespec sl[1];
sl[0].tv_nsec = 25;
while (!quit_app)
{
// read from input (DVR or other)
rlen = 0;
while (rlen BUFFY) {
int i = read(in_fd, buf + rlen, BUFFY - rlen);
if (!i) {
quit_app = 1;
continue;
}
rlen += i;
}
// write data to caio device
wlen = write(tsi_fd, buf, rlen);
if (wlen != rlen)
{
perror(Did not write same amount of data from input to caio!!!);
exit(1);
}/* else
printf(written %d bytes in tsi\n, wlen);
*/
// read data from caio device - should be decrypted
// finding sync byte
do {
buf[0] = 0;
while (buf[0] != 0x47) {
rtsilen = read(tsi_fd, buf, 1);
}
if (buf[0] == 0x47) {
do {
int i = read(tsi_fd, buf + rtsilen, 188 - rtsilen);
rtsilen += i;
// printf(reading %d bytes from tsi\n, i);
} while (rtsilen 188);
break;
}
} while (1);
//printf(sync byte found: %02x \n, buf[0]);
wtsilen = 0;
int nulls = 0;
do {
if (buf[0] == 0x47 buf[1] == 0x1F buf[2] == 0xFF) {
++nulls;
if (nulls 100)
break;
//printf(null packet );
// DVB null packet, discard
} else {
// printf(\nfrom tsi out: %x %x %x \n, buf[0], buf[1], buf[2]);
// write packet to output
int i = write(out_fd, buf, 188);
if (i 188) {
perror(Did not write 188 bytes to output file!!!);
}
wtsilen += i;
}
if (rlen == wtsilen || quit_app)
break;
rtsilen = 0;
do {
rtsilen += read(tsi_fd, buf + rtsilen, 188 - rtsilen);
} while (rtsilen 188);
} while (1);
}
close(in_fd);
close(out_fd);
close(tsi_fd);
exit(0);
}
static void signal_handler(int _signal)
{
if (!quit_app)
{
quit_app = 1;
}
}
Re: DVB nGene CI : TS Discontinuities issues
On 09/05/11 09:04, Sébastien RAILLARD (COEXSI) wrote: I don't know if CAT needs to be in the stream passed through sec0 as Sebastien mentioned, so I modified gnutv to add it to dvr. Yes, the CAT table is mandatory, it must be sent to the CAM, as well as : * the EMM PID referenced in the CAT * all the private descriptors (binary blobs) in the PMT and, of course * the ECM PID referenced in the PMT Of course, the CAM must be initialized, all the necessary CAM resources must be initialized and a CA_PMT object must be sent through the CAM command channel to ask for unscrambling of needed channels. That why it's better to send directly the raw TS output of the demodulator directly in the CAM. And then doing the demux filtering stuff on the TS stream coming from the CAM (once unscrambled). Thx Sebastien, Will check this out with gnutv and report. I think gnutv does all the init stuff you mentioned about the CAM. I will check for the possibly missing PSI packets gnutv might exclude. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 08/05/11 11:53, Andreas Oberritter wrote: Hello Issa, On 05/06/2011 08:29 PM, Issa Gorissen wrote: From: Andreas Oberritter o...@linuxtv.org On 05/06/2011 03:47 PM, Issa Gorissen wrote: Also, it seems linux en50221 stack provides for the slot selection. So, why would you need two ca nodes ? Because it's the most obvious way to use it. And more importantly because the API sucks, if you have more than one device per node. You can have only one reader, one writer, one poll function per node. For example, you can't use one instance of mplayer to watch one channel with fe0+dmx0+ca0 and a second instance of mplayer to watch or record another channel with fe1+dmx1+ca0. You won't know which device has an event if you use poll. The API even allows mixing multiple CI slots and built-in descramblers in the same node. But try calling CA_RESET on a specific slot or on a descrambler. It won't work. It's broken by design. You need to write a userspace soft which will handle the concurrent access of your ca device... ... to gain what exactly over using two distinct nodes? How do you propose solving the problem with CA_RESET with a userspace soft? Well, solving your problem of having two mplayer instances! The CA_RESET ioctl will not reset one slot at a time obviously. But you can do an interface reset via the control register, no ? In cases when you remove/add a second/third/... module from one of the slot of a CI device, then I guess the CA_RESET is broken because it will reset everything... Have you got patches for that ? But for your given example, is there any card allowing you to do that (one ci slot, two tuners) ? You don't seem to have understood my example. I was explaining some drawbacks of having more than one CI slot, but only one node, answering your prior question. Besides that, it's highly probable that such a card exists. It wouldn't make much sense to hardwire CI slots to tuners, if multiple tuners exist on a board. Disregarding the term cards, there are variants of the Dreambox with 1, 2 or 4 CI slots combined with 1 to 4 tuners. Regards, Andreas I guess your point is valid, maybe the improvement you would like to see will pop up when the need will be created... -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB nGene CI : TS Discontinuities issues
On 07/05/11 23:34, Ralph Metzler wrote:
Before blaming packet loss on the CI data path also please make
certain that you have no buffer overflows in the input part of
the sec device.
In the ngene driver you can e.g. add a printk in tsin_exchange():
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
...
} else
printk (buffer overflow \n);
Ralph,
void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)
{
struct ngene_channel *chan = priv;
struct ngene *dev = chan-dev;
if (flags DF_SWAP32)
swap_buffer(buf, len);
if (dev-ci.en chan-number == 2) {
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
dvb_ringbuffer_write(dev-tsin_rbuf, buf, len);
wake_up_interruptible(dev-tsin_rbuf.queue);
} else
printk (KERN_WARNING ngene transport interface:
tsin_exchange: buffer overflow \n);
return 0;
}
if (chan-users 0) {
dvb_dmx_swfilter(chan-demux, buf, len);
}
return NULL;
}
just prints the buffer overflow warning just after the module is loaded,
no other action made.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB nGene CI : TS Discontinuities issues
On 07/05/11 23:34, Ralph Metzler wrote:
I do not have any cxd2099 issues.
I have a simple test program which includes a 32bit counter as payload
and can pump data through the CI with full speed and have no packet
loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
but also had no problems with this.
Please take care not to write data faster than it is read. Starting two
dds will not guarantee this. To be certain you could write a small
program which never writes more packets than input buffer size minus
the number of read packets (and minus the stuffing null packets on ngene).
Before blaming packet loss on the CI data path also please make
certain that you have no buffer overflows in the input part of
the sec device.
In the ngene driver you can e.g. add a printk in tsin_exchange():
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
...
} else
printk (buffer overflow \n);
Regards,
Ralph
Ralph,
As mentioned earlier, the warning message in tsin_exchange() is somewhat
useless because it is printed endlessly at module start.
However, I've written the small test (attached) and took care to not
write more than read (not taking account of null packets).
I still cannot descrambled channels. I'm using the source from 2.6.39 rc
5 with the fix from Oliver
[http://linuxtv.org/hg/~endriss/v4l-dvb/rev/3d3e6ec2d0a7]. I launched
gnutv with output to dvr, and launched my tool to read from dvr,
write/read from sec0, write to a file.
The end result is a file which is clean of null packets, but cannot be
played by mplayer (no audio, or no video, or both...)
I don't know if CAT needs to be in the stream passed through sec0 as
Sebastien mentioned, so I modified gnutv to add it to dvr.
Sebastien, Martin, could you try Ralph suggestion and post results as
well. Thx.
Please also find an update of ngene-dvb.c, the sec device now handles
blocking/non blocking access.
--
Issa
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include signal.h
#include stdlib.h
#include stdio.h
#include unistd.h
#include time.h
static void signal_handler(int _signal);
static int quit_app = 0;
int main(int argc, char *argv[])
{
signal(SIGINT, signal_handler);
if (argc = 3)
exit(1);
int in_fd = open(argv[1], O_RDONLY);
int out_fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
int tsi_fd = open(argv[3], O_RDWR);
int rlen = 0;
int wlen = 0;
int rtsilen = 0;
int wtsilen = 0;
int BUFFY = 188 * 20;
unsigned char buf[BUFFY];
struct timespec sl[1];
sl[0].tv_nsec = 25;
while (!quit_app)
{
// read from input (DVR or other)
rlen = read(in_fd, buf, BUFFY);
if (rlen 0)
{
// write data to caio device
wlen = write(tsi_fd, buf, rlen);
if (wlen != rlen)
{
perror(Did not write same amount of data from input to caio!!!);
exit(1);
}/* else
printf(written %d bytes in tsi\n, wlen);
*/ }
if (rlen BUFFY)
{
nanosleep(sl, NULL);
}
if (rlen 188)
continue;
// read data from caio device - should be decrypted
// finding sync byte
do {
rtsilen = read(tsi_fd, buf, 1);
// printf(reading one byte: %02x from tsi\n, buf[0]);
if (rtsilen (buf[0] == 0x47)) {
do {
int i = read(tsi_fd, buf + rtsilen, 188 - rtsilen);
rtsilen += i;
// printf(reading %d bytes from tsi\n, i);
} while (rtsilen 188);
break;
}
} while (1);
//printf(sync byte found: %02x \n, buf[0]);
wtsilen = 0;
do {
// printf(from tsi out: %x %x %x \n, buf[0], buf[1], buf[2]);
if (buf[0] == 0x47 buf[1] == 0x1F buf[2] == 0xFF) {
// DVB null packet, discard
} else {
// write packet to output
wtsilen += write(out_fd, buf, 188);
}
if (rlen == wtsilen)
break;
rtsilen = 0;
do {
rtsilen += read(tsi_fd, buf + rtsilen, 188 - rtsilen);
} while (rtsilen 188);
} while (1);
}
close(in_fd);
close(out_fd);
close(tsi_fd);
exit(0);
}
static void signal_handler(int _signal)
{
if (!quit_app)
{
quit_app = 1;
}
}
/*
* ngene-dvb.c: nGene PCIe bridge driver - DVB functions
*
* Copyright (C) 2005-2007 Micronas
*
* Copyright (C) 2008-2009 Ralph Metzler r...@metzlerbros.de
* Modifications for new nGene firmware,
* support for EEPROM-copying,
* support for new dual DVB-S2 card prototype
*
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 only, as published by the Free Software Foundation.
*
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51
Re: DVB nGene CI : TS Discontinuities issues
On 03/05/11 12:59, Sébastien RAILLARD (COEXSI) wrote: Dear all, I'm doing some tests with the CI interface of the Linux4Media cineS2 DVB-S2 Twin Tuner (v5) card. I notice some TS discontinuities during my tests. My setup: - Aston Viaccess Pro CAM - Linux4Media cineS2 DVB-S2 Twin Tuner (v5) card - Latest git media_build source with DF_SWAP32 patch - DVB-S source from ASTRA 19.2E / 12285.00-V-27500 Test #1: (idle) Reading from sec0 (without CI init or sec0 input stream) using dd give me a stream of NULL TS packets of roughly 62mbps or 7.8MB/s (seems normal behavior) Command line: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 count=1 Test #2: (CAM removal) After CAM initialization and some tests, if CAM is removed, the output sec0 bandwidth isn't anymore 62mbps of NULL TS packets Same command line as Test #1 is used. It seems that the CI is badly reacting after hot remove of CAM. After rebooting, everything is fine again. Test #3: (Test dvr0 stream) - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf -out dvr CHAINE - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 - Dumping the dvr0 output: dd if=/dev/dvb/adapter14/dvr0 of=/root/test.ts bs=1880 count=1000 = The dvr0 output bandwidth is roughly 300kB/s (normal for one filtered channel) = The resulting TS file is correct (no sync missing, no continuity error) Test #4: (Loop mode - No CAM inserted) - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 of=/dev/dvb/adapter14/sec0 bs=1880 - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf -out dvr CHAINE - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 count=1 = The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is always 62mbps) = The resulting TS file is filled at 96% by NULL TS packets (normal, regarding the input stream bandwidth of 300kB/S) = All the input PID seem to present in the output file = But, there are some discontinuities in the TS packets (a lot and for all the PID) Test #5: (Trough CAM - CAM is inserted) - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 of=/dev/dvb/adapter14/sec0 bs=1880 - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf -out dvr CHAINE - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 - Waiting for CAM initialization (the CAM is correctly initialized and the PMT packet is send to the CAM) - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 count=1 = The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is always 62mbps) = The resulting TS file is filled at 96% by NULL TS packets (normal, regarding the input stream bandwidth of 300kB/S) = All the input PID seem to present in the output file = The stream isn't decoded (normal as the CAT table isn't outputted by gnutv) = But, there are some discontinuities in the TS packets (a lot and for all the PID) So, in summary, I'm observing discontinues when stream is going through the sec0 device, if CAM is present or not. Also, the CI adapter doesn't seem to react correctly when the CAM is hot removed. I can provide the TS files (from dvr0, from sec0 with CAM and without CAM) if someone is interested. Does someone has a setup that show no discontinuities when a TS stream is going through sec0? (with an input TS file) I would like to test it as for me the CI interface doesn't seem to work for the nGene cards. Best regards, Sebastien. Ralph, Could you please take a look at the cxd2099 issues ? I have attached a version with my changes. I have tested a lot of different settings with the help of the chip datasheet. Scrambled programs are not handled correctly. I don't know if it is the TICLK/MCLKI which is too high or something, or the sync detector ? Also, as we have to set the TOCLK to max of 72MHz, there are way too much null packets added. Is there a way to solve this ? Thx -- Issa /* * cxd2099.c: Driver for the CXD2099AR Common Interface Controller * * Copyright (C) 2010 DigitalDevices UG * * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 only, as published by the Free Software Foundation. * * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA * 02110-1301, USA * Or, point your browser to http://www.gnu.org/copyleft/gpl.html */ #include
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org The best would be to create independent adapters for each independent CA device (ca0/caio0 pair) - they are independent after all (physically and in the way they're used). Physically, it's a general purpose TS I/O interface of the nGene chipset. It just happens to be connected to a CI slot. On another board, it might be connected to a modulator or just to some kind of socket. If the next version gets a connector for two switchable CI modules, then the physical independence is gone. You'd have two ca nodes but only one caio node. Or two caio nodes, that can't be used concurrently. Maybe the next version gets the ability to directly connect the TS input from the frontend to the TS output to the CI slot to save copying around the data, by using some kind of pin mux. Not physically independent either. It just looks physically independent in the one configuration implemented now. When I read the cxd2099ar datasheet, I can see that in dual slot configuration, there is still one communication channel for the TS and one for the control. Also, it seems linux en50221 stack provides for the slot selection. So, why would you need two ca nodes ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org On 05/06/2011 03:47 PM, Issa Gorissen wrote: From: Andreas Oberritter o...@linuxtv.org The best would be to create independent adapters for each independent CA device (ca0/caio0 pair) - they are independent after all (physically and in the way they're used). Physically, it's a general purpose TS I/O interface of the nGene chipset. It just happens to be connected to a CI slot. On another board, it might be connected to a modulator or just to some kind of socket. If the next version gets a connector for two switchable CI modules, then the physical independence is gone. You'd have two ca nodes but only one caio node. Or two caio nodes, that can't be used concurrently. Maybe the next version gets the ability to directly connect the TS input from the frontend to the TS output to the CI slot to save copying around the data, by using some kind of pin mux. Not physically independent either. It just looks physically independent in the one configuration implemented now. When I read the cxd2099ar datasheet, I can see that in dual slot configuration, there is still one communication channel for the TS and one for the control. It doesn't matter how the cxd2099ar works, because I'm talking about the nGene chipset in place of any chipset having at least two TS inputs and one TS output. Don't know the ngene bridge enough to comment on this. Btw., I don't think the cxd2099 driver has any obvious problems. It's the nGene driver that registers the sec/caio interface. Also, it seems linux en50221 stack provides for the slot selection. So, why would you need two ca nodes ? Because it's the most obvious way to use it. And more importantly because the API sucks, if you have more than one device per node. You can have only one reader, one writer, one poll function per node. For example, you can't use one instance of mplayer to watch one channel with fe0+dmx0+ca0 and a second instance of mplayer to watch or record another channel with fe1+dmx1+ca0. You won't know which device has an event if you use poll. The API even allows mixing multiple CI slots and built-in descramblers in the same node. But try calling CA_RESET on a specific slot or on a descrambler. It won't work. It's broken by design. You need to write a userspace soft which will handle the concurrent access of your ca device... But for your given example, is there any card allowing you to do that (one ci slot, two tuners) ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org Also, there's still no mapping between ca and caio devices. Imagine a built-in descrambler ca0 and two CI slots ca1 and ca2. ca0 won't get a caio device, at least for now. ca1 and ca2 might or might not have a caio device. If there is caio0, how am I supposed to know that it's related to ca1 or ca2 (or ca0, if someone implements a caio device to bypass the software demux to use a built-in descrambler)? You must not assume that there are either none or two (or three) caio interfaces. You need to be able to detect (or set up) the connection between the interfaces. Otherwise this API will be a mess. Regards, Andreas To my understanding, in such a described case, - ca0 would be reached from /dev/dvb/adapter0/ca0 - ca[12], depending on if they are connected to the same physical adapter (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio devices. - If the 3 ca devices are on the same adapter, then the driver writer should take care of the order of the mapping so that ca1 always map caio1 and ca2/caio2, ...; and if this is not feasable, then the driver writer should span the ca/caio devices on different /dev/dvb/adapter folders. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org Of course I'm referring to devices connected to the same physical adapter. Otherwise they would all be called ca0. Device enumeration always starts at 0, for each adapter. What you're describing just doesn't make sense. Yes indeed you're right, I answered too quickly. Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device How would you support device like the Hauppauge WinTV-CI ? This one comes on a USB port and does not provide any frontend and demux device. At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. But you may want to provide a way to use the caio device for offline-descrambling. Unless you want to force users to buy multiple modules and multiple subscriptions for a single receiver, which in turn would need multiple CI slots, you need a way to make sure caio can not be used during live streaming. If this dependency is between different adapters, then something is really, really wrong. With the transmitted keys changed frequently (at least for viaccess), what's the point in supporting offline descrambling when it will not work reliably for all ? As for descrambling multiple tv channels from different transponders with only one cam, this is already possible. An example is what Digital Devices calls MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not support it. Question is, where does this belong ? kernel or userspace ? Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. I'm open to this idea, but is there a consensus on this big API change ? (deprecating ca device) If yes, I will try to prepare something. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Mauro Carvalho Chehab mche...@redhat.com It is not that simple. The question is not just how to name the interface, but that such interface will work on a different way than the current ca interface. In other words, the DVB API should clearly explain why this interface is different, when it should be used and how. Cheers, Mauro. Ok, please give me the location of the DVB API. Could not find it under the linux/Documentation folder. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
From: Lutz Sammer john...@gmx.net On 05/04/11 01:16, Mauro Carvalho Chehab wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Sorry, the things are mixed here. My patch (resend and hopefully this time not broken) handles only DVB-S transponders. The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for me. But I have very weak receiption, Johns Thank you Johns, I got out of patience and reverted back to kernel 2.6.37. Added an amplifier on the line and repositionned my dish. It works now. But very difficult to get both Hotbird 6 and 9 sats! Maybe they transmit a weak signal ??? -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device How would you support device like the Hauppauge WinTV-CI ? This one comes on a USB port and does not provide any frontend and demux device. Yes, as an exception, this device indeed wouldn't have a frontend, because it doesn't exist physycally. It wouldn't have multiple adapters numbers either. What do you mean by they shouldn't have mulitple adapters numbers ? Multiple WinTV-CI devices should have distinct node parents, ie /dev/dvb/adapter[01]/node With the transmitted keys changed frequently (at least for viaccess), what's the point in supporting offline descrambling when it will not work reliably for all ? The reliability of offline descrambling depends on the network operators policy. So while it won't be useful for everybody in the world, it might well be useful to all customers of certain operators. As for descrambling multiple tv channels from different transponders with only one cam, this is already possible. An example is what Digital Devices calls MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not support it. What's the point if it doesn't work reliably for everybody? ;-) Well, isn't it easier to change a CAM than an operator ? For many of us in France/Belgium, you might even have no choice at all for the operator. Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. I'm open to this idea, but is there a consensus on this big API change ? (deprecating ca device) If yes, I will try to prepare something. The existing API could be copied to linux/dvb/ci.h and then simplified and reviewed. As I said, if you can create a consensus behind your idea, then I will try to prepare something. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org I don't think this is going to happen, as nobody really seems to care (me included). I was just pointing out ways that I consider more likely to succeed. Regards, Andreas If you don't care, why fueling all this fuss ??? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
Em 27-03-2011 21:44, Ralph Metzler escreveu:
Hi,
since I just saw cxd2099 appear in staging in the latest git kernel, a
simple question which has been pointed out to me before:
Why is cxd2099.c in staging regarding the device name question?
It has nothing to do with the naming.
It is not just because of naming. A NACK was given to it, as is, at:
http://www.spinics.net/lists/linux-media/msg28004.html
A previous discussion about this subject were started at:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
The point is that an interface meant to be used by satellite were
used as a ci interface, due to the lack of handling independent CA devices.
As there were no final decision about a proper way to address it, Oliver
decided to keep it as-is, and I decided to move it to staging while we
don't properly address the question, extending the DVB API in order to
support
independent CA devs.
Having the driver at staging allow us to rework at the API and change the
driver when API changes are done, without needing to pass through kernel
process of deprecating old API stuff.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello all,
Here is the patch for the NGene card family and the new caio device.
Can cxd2099 be removed from staging as this patch fixes the raised issue.
Signed-off-by: Issa Gorissen flo...@usa.net
---
drivers/media/dvb/dvb-core/dvbdev.c |2 +-
drivers/media/dvb/dvb-core/dvbdev.h |1 +
drivers/media/dvb/ngene/ngene-core.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
static const char * const dnames[] = {
video, audio, sec, frontend, demux, dvr, ca,
- net, osd
+ net, osd, caio
};
#ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
#define DVB_DEVICE_CA 6
#define DVB_DEVICE_NET7
#define DVB_DEVICE_OSD8
+#define DVB_DEVICE_CAIO 9
#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
set_transfer(chan-dev-channel[2], 1);
dvb_register_device(adapter, chan-ci_dev,
ngene_dvbdev_ci, (void *) chan,
- DVB_DEVICE_SEC);
+ DVB_DEVICE_CAIO);
if (!chan-ci_dev)
goto err;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stb0899/stb6100 tuning problems
On 24/04/11 09:44, Steffen Barszus wrote: On Sat, 23 Apr 2011 22:55:27 +0200 Issa Gorissen flo...@usa.net wrote: Hi, Running kernel 2.6.39rc4. I've got trouble with tuning some transponders on Hotbird 13°E with a TT S2-3200. The transponders have been emitting DVB-S until end of march when they now emit DVB-S2 signals. They are: - 11681.00H 27500 3/4 8psk nid:319 tid:15900 on Hotbird 6 - 12692.00H 27500 3/4 8psk nid:319 tid:9900 on Hotbird 9 [1] https://patchwork.kernel.org/patch/244201/ [2] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html 1) Patch [2] is merged into kernel 2.6.39rc4. Using scan-s2, I get no service available. 2) I applied patch [1] and still could not get any service with scan-s2 from those transponders. 3) I *reverted* patch[2] and now scan-s2 returns partial results. scan-s2 can tune onto the transponder on Hotbird 6 really quick and gives back the full services list. But I have to run scan-s2 with scan iterations count set to as high as 100 to be able to get results from the transponder on Hotbird 9. When those transponders were emitting in DVB-S, I had no problem at all. Can someone try the same thing on those transponders and report please ? As mentioned before, try to use [1] + [2] + following patch. I would expect this to be working. Please confirm. --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-02-26 06:44:11.0 + +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-04-24 07:39:06.0 + @@ -1426,9 +1426,9 @@ static void stb0899_set_iterations(struc if (iter_scale config-ldpc_max_iter) iter_scale = config-ldpc_max_iter; - reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); + reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); - stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); + stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); } static enum dvbfe_search stb0899_search(struct dvb_frontend *fe, struct dvb_frontend_parameters *p) Thx for your reply. Applied [1] + [2] + your path. Unfortunately, this does not work for me. scan-s2 can tune only on the 1st of those 3 transponders on HB13E S1 12654000 H 2750 3/4 S2 12692000 H 2750 3/4 35 8PSK S2 11681000 H 2750 3/4 35 8PSK Please note that I can tune quick/fast on those 3 transponders with a ngene based card. szap will report a signal of 60% and snr of 70% for them. Problem is the CI support does not work for me. I am wondering if there is a dvb-s2 card with ci support which flawlessly works on linux... ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
Em 27-03-2011 21:44, Ralph Metzler escreveu:
Hi,
since I just saw cxd2099 appear in staging in the latest git kernel, a
simple question which has been pointed out to me before:
Why is cxd2099.c in staging regarding the device name question?
It has nothing to do with the naming.
It is not just because of naming. A NACK was given to it, as is, at:
http://www.spinics.net/lists/linux-media/msg28004.html
A previous discussion about this subject were started at:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
The point is that an interface meant to be used by satellite were
used as a ci interface, due to the lack of handling independent CA devices.
As there were no final decision about a proper way to address it, Oliver
decided to keep it as-is, and I decided to move it to staging while we
don't properly address the question, extending the DVB API in order to support
independent CA devs.
Having the driver at staging allow us to rework at the API and change the
driver when API changes are done, without needing to pass through kernel
process of deprecating old API stuff.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello all,
Here is the patch for the NGene card family and the new caio device.
Can cxd2099 be removed from staging as this patch fixes the raised issue.
Signed-off-by: Issa Gorissen flo...@usa.net
---
drivers/media/dvb/dvb-core/dvbdev.c |2 +-
drivers/media/dvb/dvb-core/dvbdev.h |1 +
drivers/media/dvb/ngene/ngene-core.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
static const char * const dnames[] = {
video, audio, sec, frontend, demux, dvr, ca,
- net, osd
+ net, osd, caio
};
#ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
#define DVB_DEVICE_CA 6
#define DVB_DEVICE_NET7
#define DVB_DEVICE_OSD8
+#define DVB_DEVICE_CAIO 9
#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
set_transfer(chan-dev-channel[2], 1);
dvb_register_device(adapter, chan-ci_dev,
ngene_dvbdev_ci, (void *) chan,
- DVB_DEVICE_SEC);
+ DVB_DEVICE_CAIO);
if (!chan-ci_dev)
goto err;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stb0899/stb6100 tuning problems
On 24/04/11 09:44, Steffen Barszus wrote: On Sat, 23 Apr 2011 22:55:27 +0200 Issa Gorissen flo...@usa.net wrote: Hi, Running kernel 2.6.39rc4. I've got trouble with tuning some transponders on Hotbird 13°E with a TT S2-3200. The transponders have been emitting DVB-S until end of march when they now emit DVB-S2 signals. They are: - 11681.00H 27500 3/4 8psk nid:319 tid:15900 on Hotbird 6 - 12692.00H 27500 3/4 8psk nid:319 tid:9900 on Hotbird 9 [1] https://patchwork.kernel.org/patch/244201/ [2] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html 1) Patch [2] is merged into kernel 2.6.39rc4. Using scan-s2, I get no service available. 2) I applied patch [1] and still could not get any service with scan-s2 from those transponders. 3) I *reverted* patch[2] and now scan-s2 returns partial results. scan-s2 can tune onto the transponder on Hotbird 6 really quick and gives back the full services list. But I have to run scan-s2 with scan iterations count set to as high as 100 to be able to get results from the transponder on Hotbird 9. When those transponders were emitting in DVB-S, I had no problem at all. Can someone try the same thing on those transponders and report please ? As mentioned before, try to use [1] + [2] + following patch. I would expect this to be working. Please confirm. --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-02-26 06:44:11.0 + +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-04-24 07:39:06.0 + @@ -1426,9 +1426,9 @@ static void stb0899_set_iterations(struc if (iter_scale config-ldpc_max_iter) iter_scale = config-ldpc_max_iter; - reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); + reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); - stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); + stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); } static enum dvbfe_search stb0899_search(struct dvb_frontend *fe, struct dvb_frontend_parameters *p) Thx for your reply. Applied [1] + [2] + your path. Unfortunately, this does not work for me. scan-s2 can tune only on the 1st of those 3 transponders on HB13E S1 12654000 H 2750 3/4 S2 12692000 H 2750 3/4 35 8PSK S2 11681000 H 2750 3/4 35 8PSK Please note that I can tune quick/fast on those 3 transponders with a ngene based card. szap will report a signal of 60% and snr of 70% for them. Problem is the CI support does not work for me. I am wondering if there is a dvb-s2 card with ci support which flawlessly works on linux... ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 00:16, Issa Gorissen wrote:
Hi all!
I'm trying to make the DVB_DEVICE_SEC approach work, however I'm
experiencing certain problems with the following setup:
Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/
http://linuxtv.org/hg/%7Eendriss/v4l-dvb/
Hardware:
Digital Devices CineS2 + CI Module
Problems:
- Packets get lost in SEC device:
I write complete TS to SEC, but when reading from SEC there are
discontinuities on the CC.
- SEC device generates NULL packets (ad infinitum):
When reading from SEC, NULL packets are read and interleaved with
expected packets. They can be even read with dd(1) when nobody is
writing to SEC and even when CAM is not ready.
- SEC device blocks on CAM re-insertion:
When CAM is removed from the slot and inserted again, all read()
operations just hang. Rebooting resolves the problem.
- SEC device does not respect O_NONBLOCK:
In connection to the previous problem, SEC device blocks even if opened
with O_NONBLOCK.
Best regards,
Martin Vidovic
Hi,
Running a bunch of test with gnutv and a DuoFLEX S2.
I saw the same problem concerning the decryption with a CAM.
I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also
applied the patch moving from SEC to CAIO.
I would run gnutv like 'gnutv -out stdout channelname
/dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -'
Mplayer would complain the file is invalid. Simply running simply 'cat
/dev/dvb/adapter0/caio0' will show me the same data pattern over and over.
Anyone using ngene based card with a CAM running successfully ?
Hi Ralph,
Could you enlighten us on the following matter please ?
I took a look inside cxd2099.c and I found that the method I suspect to
read/write data from/to the CAM are not activated.
static struct dvb_ca_en50221 en_templ = {
.read_attribute_mem = read_attribute_mem,
.write_attribute_mem = write_attribute_mem,
.read_cam_control= read_cam_control,
.write_cam_control = write_cam_control,
.slot_reset = slot_reset,
.slot_shutdown = slot_shutdown,
.slot_ts_enable = slot_ts_enable,
.poll_slot_status= poll_slot_status,
#ifdef BUFFER_MODE
.read_data = read_data,
.write_data = write_data,
#endif
};
Methods read_data and write_data are both enclosed inside the
BUFFER_MODE test. Also, current version of struct dvb_ca_en50221 does
not provide for read_data/write_data methods, right ?
If I recall right, you once told that you manage to test the CAM
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html,
how did you do ?
Thx
--
Issa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 13:37, Martin Vidovic wrote: Hi Issa, Running a bunch of test with gnutv and a DuoFLEX S2. I have a DuoFlex S2 running with CI, but not nGene based (it's attached to Octopus card - ddbridge module). I would run gnutv like 'gnutv -out stdout channelname /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over. I suspect the problem is that reads/writes are not aligned to 188 bytes with such invocation of commands. Maybe if you tried replacing 'cat' and '' with 'dd' (bs=188). Other important thing seems to be, to read from the caio0 fast enough or real data is overwritten with null packets (haven't proved it, but it looks this way on nGene). Hope this helps. Best regards, Martin Vidovic Okay, but have you managed to decode any channel yet ? I find some code odd, maybe you can take a look as well... init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0. Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 14:39, Martin Vidovic wrote: Hi, Okay, but have you managed to decode any channel yet ? Yes, I managed to descramble programmes without any problem. I find some code odd, maybe you can take a look as well... init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0. Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam They don't connect explicitly. Transfers are done implicitly through nGene ring-buffers. See demux_tasklet(). CXD code seems to be used only for CAM commands and setup (only) of data transfers. I have taken a look into the ddbrigde module code from http://linuxtv.org/hg/~endriss/ngene-octopus-test/rev/6b400d63c481 The ts_read/ts_write methods are different from the ngene module's. So I guess were are having entirely different problems. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 19:40, Oliver Endriss wrote: On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote: Running a bunch of test with gnutv and a DuoFLEX S2. I saw the same problem concerning the decryption with a CAM. I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO. If you are running 2.6.39rc4, you must apply patch http://www.mail-archive.com/linux-media@vger.kernel.org/msg29870.html Otherwise the data will be garbled. Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixes stb0899 not locking
Fixes stb0899 not locking.
See http://www.spinics.net/lists/linux-media/msg30486.html ...
When stb0899_check_data is entered, it could happen, that the data is
already locked and the data search looped. stb0899_check_data fails to
lock on a good frequency. stb0899_search_data uses an extrem big search
step and fails to lock.
The new code checks for lock before starting a new search.
The first read ignores the loop bit, for the case that the loop bit is
set during the search setup. I also added the msleep to reduce the
traffic on the i2c bus.
Johns
Signed-off-by: Lutz Sammer johns98 at gmx.net
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index 2da55ec..55f0c4e 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -338,36 +338,42 @@ static enum stb0899_status
stb0899_check_data(struct stb0899_state *state)
int lock = 0, index = 0, dataTime = 500, loop;
u8 reg;
- internal-status = NODATA;
+ reg = stb0899_read_reg(state, STB0899_VSTATUS);
+ lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
+ if ( !lock ) {
- /* RESET FEC*/
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 1);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
- msleep(1);
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 0);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
+ internal-status = NODATA;
- if (params-srate = 200)
- dataTime = 2000;
- else if (params-srate = 500)
- dataTime = 1500;
- else if (params-srate = 1500)
- dataTime = 1000;
- else
- dataTime = 500;
-
- stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force
search loop */
- while (1) {
- /* WARNING! VIT LOCKED has to be tested before
VIT_END_LOOOP*/
- reg = stb0899_read_reg(state, STB0899_VSTATUS);
- lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
- loop = STB0899_GETFIELD(VSTATUS_END_LOOPVIT, reg);
+ /* RESET FEC*/
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 1);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
+ msleep(1);
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 0);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
- if (lock || loop || (index dataTime))
- break;
- index++;
+ msleep(1);
+ }
}
if (lock) { /* DATA LOCK indicator */
Hi Johns,
I've tried your path but I had to remove the last } that you added after
the msleep(1);
The patch had not make any better the tuning of transponders on HB13E
for me.
Thanks anyway.
--
Issa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 21:14, Oliver Endriss wrote: If you are running 2.6.39rc4, you must apply patch http://www.mail-archive.com/linux-media@vger.kernel.org/msg29870.html Otherwise the data will be garbled. Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work. Basically you should not have to hack anything. - Setup the CI as with any conventional device. - Write the encrypted stream into sec0. - Read the decrypted stream from sec0. This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.) Oliver, Is there a preferred way to do this (read/write from sec0) ? I mean, does a 'gnutv -channels file -out stdout channelname sec0' and 'cat sec0 | mplayer -' should work according to your tests ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
stb0899/stb6100 tuning problems
Hi, Running kernel 2.6.39rc4. I've got trouble with tuning some transponders on Hotbird 13°E with a TT S2-3200. The transponders have been emitting DVB-S until end of march when they now emit DVB-S2 signals. They are: - 11681.00H 27500 3/4 8psk nid:319 tid:15900 on Hotbird 6 - 12692.00H 27500 3/4 8psk nid:319 tid:9900 on Hotbird 9 [1] https://patchwork.kernel.org/patch/244201/ [2] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html 1) Patch [2] is merged into kernel 2.6.39rc4. Using scan-s2, I get no service available. 2) I applied patch [1] and still could not get any service with scan-s2 from those transponders. 3) I *reverted* patch[2] and now scan-s2 returns partial results. scan-s2 can tune onto the transponder on Hotbird 6 really quick and gives back the full services list. But I have to run scan-s2 with scan iterations count set to as high as 100 to be able to get results from the transponder on Hotbird 9. When those transponders were emitting in DVB-S, I had no problem at all. Can someone try the same thing on those transponders and report please ? Thx -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 21:14, Oliver Endriss wrote: Basically you should not have to hack anything. - Setup the CI as with any conventional device. - Write the encrypted stream into sec0. - Read the decrypted stream from sec0. This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.) CU Oliver Oliver, This does not work. I have launch gnutv like this: 'gnutv -adapter 0 -channels hb.conf -out dvr -timeout 30 TF1' Then on dd tv@tv:~ dd if=188 if=/dev/dvb/adapter0/dvr0 of=/dev/dvb/adapter0/caio0 ^C36071+1 records in 36071+0 records out 18468352 bytes (18 MB) copied, 76.4947 s, 241 kB/s And another dd tv@tv:~ dd bs=188 if=/dev/dvb/adapter0/caio0 of=test.mpeg ^Cdd: reading `/dev/dvb/adapter0/caio0': Resource temporarily unavailable 1338880+0 records in 1338880+0 records out 251709440 bytes (252 MB) copied, 34.3276 s, 7.3 MB/s dd: closing input file `/dev/dvb/adapter0/caio0': Bad file descriptor The first dd reports a more/less correct size for 30sec of encrypted tv ~ 18MB. But the 2nd dd shows a big generated file out of the device. Plus it mostly contains the following pattern : lots of FF separated by 47 1F FF 10. I hope you can guide me to solve this - it is getting painful. Can we review the code together ? The starting point should be the ts_write/read methods. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ngene CI problems
Hi all! I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup: Software: Linux 2.6.34.8 (vanilla) drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/ http://linuxtv.org/hg/%7Eendriss/v4l-dvb/ Hardware: Digital Devices CineS2 + CI Module Problems: - Packets get lost in SEC device: I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC. - SEC device generates NULL packets (ad infinitum): When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready. - SEC device blocks on CAM re-insertion: When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem. - SEC device does not respect O_NONBLOCK: In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK. Best regards, Martin Vidovic Hi, Running a bunch of test with gnutv and a DuoFLEX S2. I saw the same problem concerning the decryption with a CAM. I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO. I would run gnutv like 'gnutv -out stdout channelname /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over. Anyone using ngene based card with a CAM running successfully ? -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flo...@usa.net wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? Thank you a lot, -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
Hello all,
Here is the patch for the NGene card family and the new caio device
Signed-off-by: Issa Gorissen flo...@usa.net
---
drivers/media/dvb/dvb-core/dvbdev.c |2 +-
drivers/media/dvb/dvb-core/dvbdev.h |1 +
drivers/media/dvb/ngene/ngene-core.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
static const char * const dnames[] = {
video, audio, sec, frontend, demux, dvr, ca,
- net, osd
+ net, osd, caio
};
#ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
#define DVB_DEVICE_CA 6
#define DVB_DEVICE_NET7
#define DVB_DEVICE_OSD8
+#define DVB_DEVICE_CAIO 9
#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
set_transfer(chan-dev-channel[2], 1);
dvb_register_device(adapter, chan-ci_dev,
ngene_dvbdev_ci, (void *) chan,
- DVB_DEVICE_SEC);
+ DVB_DEVICE_CAIO);
if (!chan-ci_dev)
goto err;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 13/03/11 11:47, Martin Vidovic wrote: Btw, we should choose a more meaningful name for 'camX'. I would prefer something like cainoutX or caioX or cinoutX or cioX. I agree, camX could be misleading since it's not necessarily a CAM application. According to EN 50221 the two interfaces are named Command Interface (for caX) and Transport Stream Interface (for camX). Then maybe 'tsiX' would be an appropriate name? Anyway, 'cioX' sounds good too. I'll prepare the patch with caio (for conditional access I/O) if all agrees on it. tsi is a good candidate as it perfectly matches the standard specification, but then, ca should have been ci... -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org On 03/11/2011 10:44 PM, Martin Vidovic wrote: Andreas Oberritter wrote: It's rather unintuitive that some CAMs appear as ca0, while others as cam0. Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write transport stream. To me it looks like an extension of the current API. I see. This raises another problem. How to find out, which ca device cam0 relates to, in case there are more ca devices than cam devices? Are you sure there can be more ca devices than cam devices ? Shouldn't they come by pair ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Ralph Metzler r...@metzlerbros.de Andreas Oberritter writes: Unless you want to move the writing to/reading from the CI module into ioctls of the ci device you need another node. Even nicer would be having the control messages moved to ioctls and the TS IO in read/write of ci, but this would break the old interface. It's possible to keep compatibility. Just add ioctls to get and set the interface version. Default to the current version, not supporting TS I/O. If the version is set to e.g. 1, switch from the current interface to the new one, using ioctls for control messages. A possibility, but also requires rewrites in existing software like libdvben50221. Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an unchanged libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even be on a different card) and pipe all PIDs of cam_pmt of the program you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded. This is KISS compliant by the way. Andreas, please explain what *really* bothers you with this architecture choice of having a new node, leaving the current API as is. You might find that adding a new node is lazy, but there are advantages: - current API isn't broken, namely, ca devices are still used for the control messages, nothing more; - for applications using the DVB API, it is also easier to debug while reading the code, in my opinion, because of the usage of two distinct devices (ca / cam) instead of one (ca / ioctls); -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org I'm not against adding a new node if its behaviour is well defined and documented and if it integrates well into the existing API. Integration is okay; current API is left untouched. The behaviour is defined as a write encrypted stream / read decrypted stream device. You might find that adding a new node is lazy, but there are advantages: - current API isn't broken, namely, ca devices are still used for the control messages, nothing more; nothing more is wrong, as ca devices are used for descramblers, too. I don't understand your point here, do you mean these DVB descramblers currently use ca device for more than the control messages ? - for applications using the DVB API, it is also easier to debug while reading the code, in my opinion, because of the usage of two distinct devices (ca / cam) instead of one (ca / ioctls); That's just a matter of taste. Okay, so you agree that choosing ca/ioctls over ca/cam is just a matter of taste. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org To: Issa Gorissen flo...@usa.netCc: linux-media@vger.kernel.org, r...@metzlerbros.de Subject: Re: [PATCH] Ngene cam device name On 03/10/2011 04:29 PM, Issa Gorissen wrote: As the cxd20099 driver is in staging due to abuse of the sec0 device, this patch renames it to cam0. The sec0 device is not in use and can be removed That doesn't solve anything. Besides, your patch doesn't even do what you describe. Wouldn't it be possible to extend the current CA API? If not, shouldn't a new API be created that covers both old and new requirements? It's rather unintuitive that some CAMs appear as ca0, while others as cam0. If it was that easy to fix, it wouldn't be in staging today. Regards, Andreas Yes indeed, this patch is missing the update of dnames arrays in dvbdev.c Now, according to Mauro comments, he has put this code into staging because of the usage of sec0 name for a cam device. Please comment on Oliver's explanations from this thread http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html Thx -- Issa Signed-off-by: Issa Gorissen flo...@usa.net --- drivers/media/dvb/dvb-core/dvbdev.h |2 +- drivers/media/dvb/ngene/ngene-core.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvbdev.h b/drivers/media/dvb/dvb-core/dvbdev.h index fcc6ae9..dcac27d 100644 --- a/drivers/media/dvb/dvb-core/dvbdev.h +++ b/drivers/media/dvb/dvb-core/dvbdev.h @@ -40,7 +40,7 @@ #define DVB_DEVICE_VIDEO 0 #define DVB_DEVICE_AUDIO 1 -#define DVB_DEVICE_SEC2 +#define DVB_DEVICE_CAM2 #define DVB_DEVICE_FRONTEND 3 #define DVB_DEVICE_DEMUX 4 #define DVB_DEVICE_DVR5 diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c index 175a0f6..6be2d7c 100644 --- a/drivers/media/dvb/ngene/ngene-core.c +++ b/drivers/media/dvb/ngene/ngene-core.c @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan) set_transfer(chan-dev-channel[2], 1); dvb_register_device(adapter, chan-ci_dev, ngene_dvbdev_ci, (void *) chan, - DVB_DEVICE_SEC); + DVB_DEVICE_CAM); if (!chan-ci_dev) goto err; } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Ngene cam device name
As the cxd20099 driver is in staging due to abuse of the sec0 device, this patch renames it to cam0. The sec0 device is not in use and can be removed Signed-off-by: Issa Gorissen flo...@usa.net --- drivers/media/dvb/dvb-core/dvbdev.h |2 +- drivers/media/dvb/ngene/ngene-core.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvbdev.h b/drivers/media/dvb/dvb-core/dvbdev.h index fcc6ae9..dcac27d 100644 --- a/drivers/media/dvb/dvb-core/dvbdev.h +++ b/drivers/media/dvb/dvb-core/dvbdev.h @@ -40,7 +40,7 @@ #define DVB_DEVICE_VIDEO 0 #define DVB_DEVICE_AUDIO 1 -#define DVB_DEVICE_SEC2 +#define DVB_DEVICE_CAM2 #define DVB_DEVICE_FRONTEND 3 #define DVB_DEVICE_DEMUX 4 #define DVB_DEVICE_DVR5 diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c index 175a0f6..6be2d7c 100644 --- a/drivers/media/dvb/ngene/ngene-core.c +++ b/drivers/media/dvb/ngene/ngene-core.c @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan) set_transfer(chan-dev-channel[2], 1); dvb_register_device(adapter, chan-ci_dev, ngene_dvbdev_ci, (void *) chan, - DVB_DEVICE_SEC); + DVB_DEVICE_CAM); if (!chan-ci_dev) goto err; } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sony CXD2099AR support
Hi, I have read that this CI chip driver is in staging because some questions on how to handle it are still not answered. I volunteer to handle this one. I'm a regular java developer, but I'm willing to put effort in learning linux drivers writing. So Ralph, can you give me some pointers on where the discussion should resume ? Do we put people of Mythtv and VDR in the discussion ? I guess so. I don't see anything related to MTD in the DVB CSA documents. I guess this should be left out of the driver. Thx, -- Issa -- Original Message -- Received: 11:48 AM CET, 02/25/2011 From: Issa Gorissen flo...@usa.net To: linux-media@vger.kernel.org Subject: Re: Sony CXD2099AR decryption failing Follow up on the trouble with Digital Devices DuoFlex S2, CI, SMIT Viaccess CAM and Bis.tv card. The whole combination works under Windows 7 with Media Center. I have been able to watch and change channels I'm entitled to in the Bis.TV package. Only condition was to disable CI for tuner no 2. If the CI is activated for tuner 1 and tuner 2, Media Center will not be able to change the channels. Anything I can do to make progress for this issue under linux ? Thx -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sony CXD2099AR decryption failing
Follow up on the trouble with Digital Devices DuoFlex S2, CI, SMIT Viaccess CAM and Bis.tv card. The whole combination works under Windows 7 with Media Center. I have been able to watch and change channels I'm entitled to in the Bis.TV package. Only condition was to disable CI for tuner no 2. If the CI is activated for tuner 1 and tuner 2, Media Center will not be able to change the channels. Anything I can do to make progress for this issue under linux ? Thx -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sony CXD2099AR decryption failing
Hi Oliver, I have managed to make a test under Windows. It worked. I only managed to watch France 2 with BIS.TV card and SMIT Viaccess CAM with MediaPortal 1.2.0 Alpha. What's the next step, shall I do another test ? Support from DD tells me this Name: Manfred Völkel Message: Hello Issa The SMIT Viaccess has originally been testet with a SRG card. After restesting now i have indeed found a problem with the BIS Card and the SMIT Viaccess module. This combination does not work reliable with MTD. It however works in single transponder mode, which is the only mode currently supported with Linux (until someone writes plugins for VDR etc tu remux). Please assign only one tuner to the CI and also configure WMC with only one tuner and retest. This worked here. My BIS card's serial starts with 400 00 xxx The SMIT Viaccess: Hardware Version 1.3.0(221) Loader Version: 4.2.3 seq:2 Software version: 1.6.1(166)m2 UA: 000 000 000 000 STB identifier: . ACS Version: 463-2.1.2.11 Gruß DD-Guru -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sony CXD2099AR decryption failing
Hello Oliver, I've managed to run Win 7 on the computer. Tested the encrypted channels with WIndows Media Center and the DigitalDevices driver version 2.1.0.30. I cannot get the channels to show up. MCE shows an error stating that those channels are encrypted or there are no signals for them. FTA works. Any suggestion from here ? I've read on the digital devices FAQ that the SMIT viaccess CAM has been successfully tested... Thx -- Issa -- Original Message -- Received: 11:55 AM CET, 02/15/2011 From: Issa Gorissen flo...@usa.net To: linux-media@vger.kernel.org Subject: Re: Sony CXD2099AR decryption failing Hi Oliver, Thx for your reply. This will be a bit hard. But I will give it a try. I will try to boot from a USB key with Windows on it. Any preferences for Windows ? XP, Vista or 7 ? -- Issa -- Original Message -- Received: 04:04 AM CET, 02/15/2011 From: Oliver Endriss o.endr...@gmx.de To: Issa Gorissen flo...@usa.netCc: linux-media@vger.kernel.org Subject: Re: Sony CXD2099AR decryption failing Hello, On Monday 14 February 2011 17:42:55 Issa Gorissen wrote: Hi, I am having some trouble with the Sony CXD2099AR CI chip. With a SMIT Viaccess CAM, I am not able to decrypt channels from the french package Bis.TV on Hotbird 13E. The CAM decrypts fine when inserted in a set top box. The drivers running are those from the branch of Oliver. System's running OpenSuse 11.3. May someone with the knowledge of this chip get in touch with me ? Could you please test, whether it works with the windows driver? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sony CXD2099AR decryption failing
Hi Oliver, Thx for your reply. This will be a bit hard. But I will give it a try. I will try to boot from a USB key with Windows on it. Any preferences for Windows ? XP, Vista or 7 ? -- Issa -- Original Message -- Received: 04:04 AM CET, 02/15/2011 From: Oliver Endriss o.endr...@gmx.de To: Issa Gorissen flo...@usa.netCc: linux-media@vger.kernel.org Subject: Re: Sony CXD2099AR decryption failing Hello, On Monday 14 February 2011 17:42:55 Issa Gorissen wrote: Hi, I am having some trouble with the Sony CXD2099AR CI chip. With a SMIT Viaccess CAM, I am not able to decrypt channels from the french package Bis.TV on Hotbird 13E. The CAM decrypts fine when inserted in a set top box. The drivers running are those from the branch of Oliver. System's running OpenSuse 11.3. May someone with the knowledge of this chip get in touch with me ? Could you please test, whether it works with the windows driver? CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sony CXD2099AR decryption failing
Hi, I am having some trouble with the Sony CXD2099AR CI chip. With a SMIT Viaccess CAM, I am not able to decrypt channels from the french package Bis.TV on Hotbird 13E. The CAM decrypts fine when inserted in a set top box. The drivers running are those from the branch of Oliver. System's running OpenSuse 11.3. May someone with the knowledge of this chip get in touch with me ? Thx, -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
