Date:	Wed, 6 Dec 2006 15:18:12 -0500
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Ivo van Doorn" <ivdoorn@...il.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	"John Linville" <linville@...driver.com>,
	"Jiri Benc" <jbenc@...e.cz>,
	"Lennart Poettering" <lennart@...ttering.net>,
	"Johannes Berg" <johannes@...solutions.net>,
	"Larry Finger" <Larry.Finger@...inger.net>
Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio

On 12/6/06, Ivo van Doorn <ivdoorn@...il.com> wrote:
> On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote:
> > On 12/4/06, Ivo van Doorn <ivdoorn@...il.com> wrote:
> > > > I am still not sure that tight coupling of input device with rfkill
> > > > structure is such a good idea. Quite often the button is separated
> > > > from the device itself and radio control is done via BIOS SMM (see
> > > > wistron driver) or there is no special button at all and users might
> > > > want to assign one of their standard keyboard buttons to be an RF
> > > > switch.
> > >
> > > Making sure rfkill supports keys that are not handled by the driver
> > > is a bit hard. Just as drivers that can only check if the button is
> > > toggled and not what the current state is.
> > > The problem is that it is hard to make a clean split between the
> > > 2 different button controls. Not all drivers allow the radio to be
> > > enabled while the button status are indicating the radio should
> > > be off.
> >
> > If they do not allow controlling the state of the radio
> > programmatically then it should not be part of rfkill I am afraid. It
> > is like the power switch - if you hold it for so long it kills the
> > power to the box and there is nothing you can do about it.
>
> Ok, this will give rfkill more possibilities as I could in that case
> also allow the user to toggle the radio to the state that is different
> than indicated by the key.
> Currently this was not possible since I had to keep in mind that there
> were keys that would directly control the radio.
>
> > > The buttons that are already integrated into the keyboard,
> > > by example by using a Fn key combo don't control the device
> > > directly. So the driver cannot offer anything to the rfkill driver.
> > > Such buttons should be mapped in userspace without the help of rfkill,
> > > since the kernel cannot detect if that key belonged to a radio
> > > control key or not.
> > >
> >
> > That is my point. Given the fact that there are keys that are not
> > directly connected with the radio switch userspace will have to handle
> > them (wait for events then turn off radios somehow). You are
> > advocating that userspace should also implement 2nd method for buttons
> > that belong to rfkill interface. I do not understand the need for 2nd
> > interface. If you separate radio switch from button code then
> > userspace only need to implement 1st interface and be done with it.
> > You will have set of cards that provide interface to enable/disable
> > their transmitters and set of buttons that signal userspace desired
> > state change. If both switch and button is implemented by the same
> > driver then the driver can implement automatic button handling.
> > Otherwise userspace help is necessary.
>
> Well there are 3 possible hardware key approaches:
>
>  1 - Hardware key that controls the hardware radio, and does not report anything to userspace

Can't do anything here so just ignore it.

>  2 - Hardware key that does not control the hardware radio and does not report anything to userspace

Kind of uninteresting button ;)

>  3 - Hardware key that does not control the hardware radio and reports the key to userspace
>
> So rfkill should not be used in the case of (1) and (3), but we still need something to support (2)
> or should the keys not be handled by userspace and always by the driver?
> This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial
> intention was.
>

I my "vision" rfkill would represent userspace namageable radio
switch. We have the followng possible configurations:

1. A device that does not allow controlling its transmitter from
userspace. The driver should not use/register with rfkill subsystem as
userspace can't do anyhting with it. If device has a button killing
the transmitter the driver can still signal userspace appropriate
event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was
presssed so userspace can monitor state of the transmitter and
probably shut down other transmitters to keep everything in sync.

2. A device that does allow controlling its transmitter. The driver
may (should) register with rfkill subsystem. Additionally, if there is
a button, the driver should register it with input subsystem. Driver
should manage transmitter state in response to button presses unless
userspace takes over the process.

3. A device without transmitter but with a button - just register with
input core. Userspace will have to manage state of other devices with
transmitters in response to button presses.

Does this make sense?

> > > > attribute should be a tri-state on/off/auto, "auto" meaning the driver
> > > > itself manages radio state. This would avoid another tacky IMHO point
> > > > that in your implementation mere opening of an input device takes over
> > > > RF driver. Explicit control allow applications "snoop" RF state
> > > > without disturbing it.
> > >
> > > Currently userspace can always check the state of the button whenever
> > > they like by checking the sysfs entry.
> > >
> >
> > Unless the key is not directly connected to the driver (so there is no
> > sysfs entry). Again you force 2 different interfaces.
>
> Ok, so input device opening should not block the rfkill signal and the rfkill handler
> should still go through with its work unless a different config option indicates that
> userspace wants to handle the event.
>

I don't think a config option is a good idea unless by config option
you mean a sysfs attribute.

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