[PATCH] [media] rc: do not enable remote controller adapters by default.

[PATCH] [media] rc: do not enable remote controller adapters by default.

[Stephen Wilson]

Having the RC_CORE config default to INPUT is almost equivalent to
saying "yes".  Default to "no" instead.

Signed-off-by: Stephen Wilson <wilsons@start.ca>
---
 drivers/media/rc/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 3785162..8842843 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -1,7 +1,7 @@
 menuconfig RC_CORE
 	tristate "Remote Controller adapters"
 	depends on INPUT
-	default INPUT
+	default n
 	---help---
 	  Enable support for Remote Controllers on Linux. This is
 	  needed in order to support several video capture adapters.
--
1.7.3.5

Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

[Andy Walls]

On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
> Having the RC_CORE config default to INPUT is almost equivalent to
> saying "yes".  Default to "no" instead.
> 
> Signed-off-by: Stephen Wilson <wilsons@start.ca>

I don't particularly like this, if it discourages desktop distributions
from building RC_CORE.  The whole point of RC_CORE in kernel was to have
the remote controllers bundled with TV and DTV cards "just work" out of
the box for end users.  Also the very popular MCE USB receiver device,
shipped with Media Center PC setups, needs it too.

Why exactly do you need it set to "No"?

Regards,
Andy

> ---
>  drivers/media/rc/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 3785162..8842843 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -1,7 +1,7 @@
>  menuconfig RC_CORE
>  	tristate "Remote Controller adapters"
>  	depends on INPUT
> -	default INPUT
> +	default n
>  	---help---
>  	  Enable support for Remote Controllers on Linux. This is
>  	  needed in order to support several video capture adapters.
> --
> 1.7.3.5
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

[Stephen Wilson]

Andy Walls <awalls@md.metrocast.net> writes:

> On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
>> Having the RC_CORE config default to INPUT is almost equivalent to
>> saying "yes".  Default to "no" instead.
>>
>> Signed-off-by: Stephen Wilson <wilsons@start.ca>
>
> I don't particularly like this, if it discourages desktop distributions
> from building RC_CORE.  The whole point of RC_CORE in kernel was to have
> the remote controllers bundled with TV and DTV cards "just work" out of
> the box for end users.  Also the very popular MCE USB receiver device,
> shipped with Media Center PC setups, needs it too.

A similar argument can be made for any particular feature or device that
just works when the functionality is enabled :)

> Why exactly do you need it set to "No"?

It is not a need.  I simply observed that after the IR_ to RC_ rename
there was another set of drivers being built which I did not ask for.

It struck me as odd that because basic keyboard/mouse support was
enabled I also got support for DTV card remote controls.

I don't think there are any other driver subsystems enabling themselves
based on something as generic as INPUT (as a dependency it is just fine,
obviously).

Overall, it just seems like the wrong setting to me.  Is there another
predicate available that makes a bit more sense for RC_CORE other than
INPUT?  Something related to the TV or DTV cards perhaps?


Take care,

>
> Regards,
> Andy
>
>> ---
>>  drivers/media/rc/Kconfig |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
>> index 3785162..8842843 100644
>> --- a/drivers/media/rc/Kconfig
>> +++ b/drivers/media/rc/Kconfig
>> @@ -1,7 +1,7 @@
>>  menuconfig RC_CORE
>>  	tristate "Remote Controller adapters"
>>  	depends on INPUT
>> -	default INPUT
>> +	default n
>>  	---help---
>>  	  Enable support for Remote Controllers on Linux. This is
>>  	  needed in order to support several video capture adapters.
>> --
>> 1.7.3.5
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
steve

Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

[Jarod Wilson]

On Wed, Feb 16, 2011 at 10:09:44AM -0500, Stephen Wilson wrote:
> Andy Walls <awalls@md.metrocast.net> writes:
> 
> > On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
> >> Having the RC_CORE config default to INPUT is almost equivalent to
> >> saying "yes".  Default to "no" instead.
> >>
> >> Signed-off-by: Stephen Wilson <wilsons@start.ca>
> >
> > I don't particularly like this, if it discourages desktop distributions
> > from building RC_CORE.  The whole point of RC_CORE in kernel was to have
> > the remote controllers bundled with TV and DTV cards "just work" out of
> > the box for end users.  Also the very popular MCE USB receiver device,
> > shipped with Media Center PC setups, needs it too.
> 
> A similar argument can be made for any particular feature or device that
> just works when the functionality is enabled :)
> 
> > Why exactly do you need it set to "No"?
> 
> It is not a need.  I simply observed that after the IR_ to RC_ rename
> there was another set of drivers being built which I did not ask for.

So disable them. I think most people would rather have this support
enabled so that remotes Just Work if a DTV card or stand-alone IR receiver
is plugged in without having to hunt back through Kconfig options to
figure out why it doesn't...

> It struck me as odd that because basic keyboard/mouse support was
> enabled I also got support for DTV card remote controls.
> 
> I don't think there are any other driver subsystems enabling themselves
> based on something as generic as INPUT (as a dependency it is just fine,
> obviously).
> 
> Overall, it just seems like the wrong setting to me.  Is there another
> predicate available that makes a bit more sense for RC_CORE other than
> INPUT?  Something related to the TV or DTV cards perhaps?

No. As Andy said, there are stand-alone devices, such as the Windows Media
Center Ed. eHome Infrared Transceivers which are simply a usb device, no
direct relation to any TV devices. A fair number of systems these days are
also shipping with built-in CIR support by way of a sub-function on an LPC
SuperIO chip. Remotes can be used to control more than just changing
channels on a TV tuner card (think music player, video playback app
streaming content from somewhere on the network, etc).

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

[Stephen Wilson]

Jarod Wilson <jarod@redhat.com> writes:

> On Wed, Feb 16, 2011 at 10:09:44AM -0500, Stephen Wilson wrote:
>> Andy Walls <awalls@md.metrocast.net> writes:
>>
>> > On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
>> >> Having the RC_CORE config default to INPUT is almost equivalent to
>> >> saying "yes".  Default to "no" instead.
>> >>
>> >> Signed-off-by: Stephen Wilson <wilsons@start.ca>
>> >
>> > I don't particularly like this, if it discourages desktop distributions
>> > from building RC_CORE.  The whole point of RC_CORE in kernel was to have
>> > the remote controllers bundled with TV and DTV cards "just work" out of
>> > the box for end users.  Also the very popular MCE USB receiver device,
>> > shipped with Media Center PC setups, needs it too.
>>
>> A similar argument can be made for any particular feature or device that
>> just works when the functionality is enabled :)
>>
>> > Why exactly do you need it set to "No"?
>>
>> It is not a need.  I simply observed that after the IR_ to RC_ rename
>> there was another set of drivers being built which I did not ask for.
>
> So disable them. I think most people would rather have this support
> enabled so that remotes Just Work if a DTV card or stand-alone IR receiver
> is plugged in without having to hunt back through Kconfig options to
> figure out why it doesn't...
>
>> It struck me as odd that because basic keyboard/mouse support was
>> enabled I also got support for DTV card remote controls.
>>
>> I don't think there are any other driver subsystems enabling themselves
>> based on something as generic as INPUT (as a dependency it is just fine,
>> obviously).
>>
>> Overall, it just seems like the wrong setting to me.  Is there another
>> predicate available that makes a bit more sense for RC_CORE other than
>> INPUT?  Something related to the TV or DTV cards perhaps?
>
> No. As Andy said, there are stand-alone devices, such as the Windows Media
> Center Ed. eHome Infrared Transceivers which are simply a usb device, no
> direct relation to any TV devices. A fair number of systems these days are
> also shipping with built-in CIR support by way of a sub-function on an LPC
> SuperIO chip. Remotes can be used to control more than just changing
> channels on a TV tuner card (think music player, video playback app
> streaming content from somewhere on the network, etc).

OK.  No problem.  Thanks for for taking the time to explain!

--
steve

Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

[VDR User]

On Wed, Feb 16, 2011 at 7:20 AM, Jarod Wilson <jarod@redhat.com> wrote:
>> It is not a need.  I simply observed that after the IR_ to RC_ rename
>> there was another set of drivers being built which I did not ask for.
>
> So disable them. I think most people would rather have this support
> enabled so that remotes Just Work if a DTV card or stand-alone IR receiver
> is plugged in without having to hunt back through Kconfig options to
> figure out why it doesn't...

Unfortunately _ALL_ the usb DVB devices are unavailable if you do not
enable IR_CORE "Infrared remote controller adapters" in v4l.  This is
a little annoying as the usb device I use doesn't even have IR
capabilities.  It doesn't seem like something that should be forced on
the user -- enable IR or you can't even compile the driver you need,
which doesn't even use IR.

It's not the end of the world but I don't particularly appreciate the
enable-everything approach.  It would be nice to at least have the
option to trim the fat if you want.. Isn't that partially what Linux
is supposed to be about in the first place?

Just my two cents...

Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

[Mauro Carvalho Chehab]

Em 16-02-2011 15:25, VDR User escreveu:
> On Wed, Feb 16, 2011 at 7:20 AM, Jarod Wilson <jarod@redhat.com> wrote:
>>> It is not a need.  I simply observed that after the IR_ to RC_ rename
>>> there was another set of drivers being built which I did not ask for.
>>
>> So disable them. I think most people would rather have this support
>> enabled so that remotes Just Work if a DTV card or stand-alone IR receiver
>> is plugged in without having to hunt back through Kconfig options to
>> figure out why it doesn't...
> 
> Unfortunately _ALL_ the usb DVB devices are unavailable if you do not
> enable IR_CORE "Infrared remote controller adapters" in v4l.  This is
> a little annoying as the usb device I use doesn't even have IR
> capabilities.  It doesn't seem like something that should be forced on
> the user -- enable IR or you can't even compile the driver you need,
> which doesn't even use IR.
> 
> It's not the end of the world but I don't particularly appreciate the
> enable-everything approach.  It would be nice to at least have the
> option to trim the fat if you want.. Isn't that partially what Linux
> is supposed to be about in the first place?

Unfortunately, the way almost all drivers/media/[video|dvb] was made,
the IR (and input support on webcams) are tighted to the driver.

It would be possible to change it (and it is not that hard), but it requires 
people with enough time and skills to go into each driver that can support IR, 
split the IR code into a separate module and be sure that the driver will 
compile and work with or without IR support.

Cheers,
Mauro