From: "Issa Gorissen" <flop.m@usa.net>
To: Andreas Oberritter <obi@linuxtv.org>
Cc: <linux-media@vger.kernel.org>
Subject: Re: [PATCH] Ngene cam device name
Date: Wed, 04 May 2011 16:05:02 +0200 [thread overview]
Message-ID: <208PeDoec2016S01.1304517902@web01.cms.usa.net> (raw)
From: Andreas Oberritter <obi@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.
next reply other threads:[~2011-05-04 14:05 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 14:05 Issa Gorissen [this message]
2011-05-04 14:27 ` [PATCH] Ngene cam device name Andreas Oberritter
-- strict thread matches above, loose matches on Subject: below --
2011-05-06 18:29 Issa Gorissen
2011-05-08 9:53 ` Andreas Oberritter
2011-05-08 10:30 ` Issa Gorissen
2011-05-06 13:47 Issa Gorissen
2011-05-06 16:07 ` Andreas Oberritter
2011-05-04 14:51 Issa Gorissen
2011-05-04 11:09 Issa Gorissen
2011-05-04 11:07 Issa Gorissen
2011-05-04 13:51 ` Andreas Oberritter
2011-05-04 8:27 Issa Gorissen
2011-05-04 9:59 ` Andreas Oberritter
2011-05-04 11:20 ` Ralph Metzler
2011-05-04 12:30 ` Andreas Oberritter
2011-05-04 13:15 ` Ralph Metzler
2011-05-04 13:35 ` Martin Vidovic
2011-05-04 14:46 ` Andreas Oberritter
2011-05-05 14:43 ` Martin Vidovic
2011-05-06 12:17 ` Andreas Oberritter
2011-05-06 13:43 ` Walter Van Eetvelt
2011-05-08 10:05 ` Martin Vidovic
2011-05-08 17:58 ` Andreas Oberritter
2011-05-08 23:55 ` Martin Vidovic
2011-05-09 11:44 ` Andreas Oberritter
2011-04-24 11:38 Issa Gorissen
2011-05-03 23:11 ` Mauro Carvalho Chehab
2011-05-04 7:24 ` Andreas Oberritter
2011-03-12 15:39 Issa Gorissen
2011-03-12 14:34 Issa Gorissen
2011-03-12 14:58 ` Andreas Oberritter
2011-03-28 0:44 ` Ralph Metzler
2011-03-28 21:40 ` Mauro Carvalho Chehab
2011-04-24 9:31 ` Issa Gorissen
2011-03-28 22:57 ` Oliver Endriss
2011-04-05 21:50 ` Issa Gorissen
2011-03-12 14:10 Issa Gorissen
2011-03-12 14:48 ` Andreas Oberritter
2011-03-12 14:57 ` Martin Vidovic
2011-03-12 15:06 ` Andreas Oberritter
2011-03-11 18:33 Issa Gorissen
2011-03-11 20:39 ` Andreas Oberritter
2011-03-11 21:46 ` Ralph Metzler
2011-03-12 13:25 ` Andreas Oberritter
2011-03-12 13:55 ` Ralph Metzler
2011-03-10 15:29 Issa Gorissen
2011-03-11 15:52 ` Andreas Oberritter
2011-03-11 21:44 ` Martin Vidovic
2011-03-12 13:29 ` Andreas Oberritter
2011-03-12 14:05 ` Ralph Metzler
2011-03-12 14:38 ` Andreas Oberritter
2011-03-12 15:06 ` Ralph Metzler
2011-03-12 23:42 ` Oliver Endriss
2011-03-13 10:47 ` Martin Vidovic
2011-03-16 22:07 ` Issa Gorissen
2011-03-18 20:20 ` Martin Vidovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=208PeDoec2016S01.1304517902@web01.cms.usa.net \
--to=flop.m@usa.net \
--cc=linux-media@vger.kernel.org \
--cc=obi@linuxtv.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.