All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@linuxtv.org>
To: Issa Gorissen <flop.m@usa.net>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH] Ngene cam device name
Date: Wed, 04 May 2011 16:27:56 +0200	[thread overview]
Message-ID: <4DC1626C.1020206@linuxtv.org> (raw)
In-Reply-To: <208PeDoec2016S01.1304517902@web01.cms.usa.net>

On 05/04/2011 04:05 PM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>> 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>

I wrote "wouldn't", not "shouldn't". I'm fine with it.

>>> 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.

Again it depends on the operator, whether getting a working CAM at all
is possible, putting aside that there's no guarantee that it would work
with "MTD". But I really don't mind. See the smiley. I was just
referring to your similar question. I wasn't going to tell that foo was
better than or even related to bar, but just that foo is a good feature
for many people. I also consider bar a good feature.

>>>> 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.

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

  reply	other threads:[~2011-05-04 14:28 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04 14:05 [PATCH] Ngene cam device name Issa Gorissen
2011-05-04 14:27 ` Andreas Oberritter [this message]
  -- 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=4DC1626C.1020206@linuxtv.org \
    --to=obi@linuxtv.org \
    --cc=flop.m@usa.net \
    --cc=linux-media@vger.kernel.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.