On Mon, Jan 11, 2016 at 8:02 PM, Bastien Nocera <hadess(a)hadess.net> wrote:
On Mon, 2016-01-11 at 14:21 -0500, Josh Boyer wrote:
> On Sun, Jan 10, 2016 at 7:54 AM, Bastien Nocera <bnocera(a)redhat.com>
> wrote:
> > From: Bastien Nocera <hadess(a)hadess.net>
> >
> > As noted in
https://www.kernel.org/doc/Documentation/rfkill.txt
> > rfkill-input is deprecated, and rfkill keys are handled in user-
> > space.
>
> That may be what the document says, but the Kconfig at least seems to
> imply something else.
What says that in the Kconfig?
The fact that disabling it is still enforced behind CONFIG_EXPERT
upstream. It's certainly likely that people are terrible at cleaning
up and it should have been done long ago, but it wasn't.
This is the relevant commit which explains what rfkill-input is used
for (basically, if you don't have a desktop environment and you still
want the keys to work):
commit c64fb01627e24725d1f9d535e4426475a4415753
Author: Johannes Berg <johannes(a)sipsolutions.net>
Date: Tue Jun 2 13:01:38 2009 +0200
rfkill: create useful userspace interface
The new code added by this patch will make rfkill create
a misc character device /dev/rfkill that userspace can use
to control rfkill soft blocks and get status of devices as
well as events when the status changes.
Using it is very simple -- when you open it you can read
a number of times to get the initial state, and every
further read blocks (you can poll) on getting the next
event from the kernel. The same structure you read is
also used when writing to it to change the soft block of
a given device, all devices of a given type, or all
devices.
This also makes CONFIG_RFKILL_INPUT selectable again in
order to be able to test without it present since its
functionality can now be replaced by userspace entirely
and distros and users may not want the input part of
rfkill interfering with their userspace code. We will
also write a userspace daemon to handle all that and
consequently add the input code to the feature removal
schedule.
The feature removal schedule doesn't exist anymore and hasn't for a
number of years. Even if it did, the feature is clearly not removed.
Out of curiosity, which daemon(s) handle the "new" interface?
In order to have rfkilld support both kernels with and
without CONFIG_RFKILL_INPUT (or new kernels after its
eventual removal) we also add an ioctl (that only exists
if rfkill-input is present) to disable rfkill-input.
It is not very efficient, but at least gives the correct
behaviour in all cases.
Signed-off-by: Johannes Berg <johannes(a)sipsolutions.net>
Acked-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: John W. Linville <linville(a)tuxdriver.com>
Does it really make sense to cater for that use?
No. I don't really care either way. But did you even read the rest
of my original email? I can't turn it off without turning on
CONFIG_EXPERT, and I'm not going to do that. Also, did you test your
patch on e.g. Fedora Workstation?
So perhaps pursue dropping that requirement upstream, or just deleting
the whole thing entirely. It was originally scheduled to be removed
in 2.6.33, which was 6 years ago.
josh