lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m34o83kime.fsf@fibrous.localdomain>
Date:	Wed, 16 Feb 2011 12:13:29 -0500
From:	Stephen Wilson <wilsons@...rt.ca>
To:	Jarod Wilson <jarod@...hat.com>
Cc:	Stephen Wilson <wilsons@...rt.ca>,
	Andy Walls <awalls@...metrocast.net>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	David Härdeman <david@...deman.nu>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

Jarod Wilson <jarod@...hat.com> writes:

> On Wed, Feb 16, 2011 at 10:09:44AM -0500, Stephen Wilson wrote:
>> Andy Walls <awalls@...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@...rt.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ