On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
