Date:	Sun, 3 Dec 2006 23:16:55 +0100
From:	Ivo van Doorn <ivdoorn@...il.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Dmitry Torokhov <dtor@...ightbb.com>, 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>, davidz@...hat.com,
	Bastien Nocera <bnocera@...hat.com>
Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio

Hi,

> > This patch is a resend of a patch I has been send to the linux kernel
> > and netdev list earlier. The most recent version of a few weeks back
> > didn't compile since I missed 1 line in my patch that changed
> > include/linux/input.h.
> > 
> > This patch will offer the handling of radiokeys on a laptop.
> > Such keys often control the wireless devices on the radio
> > like the wifi, bluetooth and irda.
> 
> Ok, what was the conclusion on the following issues?
> 
> 1) What about rfkill keys that aren't routed via software?  There are
> two modes here: (a) the key is not hardwired to the module and the
> driver is responsible for disabling the radio, (b) the key is hardwired
> to the module and firmware or some other mechanism disables the radio
> without driver interaction.  I thought I'd heard of some (b) hardware,
> mostly on older laptops, but does anyone know how prevalent (b) hardware
> is?  If there isn't any, do we care about it for now?

On condition
a)
The driver is supposed to read the button status by the method provided by
the device. (i.e. reading the register) the rfkill will periodically poll the driver
(if the polling method has been provided by the driver) and the rfkill
will do its work when the status of the register has changed.
With the input device open, the user can listen to the events and switch off
the radio manually (by using a tool like ifconfig or through the sysfs field)
When the input device is not open, rfkill will use the driver provided callback
functions to enable or disable the radio.

b)
In this case an interrupt is usually send to the driver about the event, or still the
register will be possible. On both occassions the signal can still be caught by
rfkill and handled further.
If the event is send to userspace so the user can still perform tasks,
the user can however not use the sysfs field to change the radio status
since it is only allowed to switch the radio to the status that the button indicates.
But the user can still perform tasks that should be handled (like stopping
programs that need the network).

I have heard that the broadcom chipsets toggle the radio state without
intervention of the driver, and instead only send an interrupt event.

> 2) Is there hardware that has separate keys for separate radios?  i.e.,
> one key for Bluetooth, and one key for WiFi?  I know Bastien has a
> laptop where the same rfkill key handles _both_ ipw2200 and the BT
> module, but in different ways: it actually removes the BT USB device
> from the USB bus, but uses the normal ipw rfkill mechanism.

Don't know about this hardware, my laptop has 2 seperate buttons for wifi
and bluetooth.
But it would be quite hard to caught such events cleanly, in this case the
option would be to register 2 seperate rfkill_key structures. That way the
key is represented twice to the user. But the enable_radio and disable _radio
callback functions from the driver would make the callback for the wifi and
bluetooth radio  individually possibly.

> 3) How does this interact with HAL?  What's the userspace interface that
> HAL will listen to to receive the signals?  NetworkManager will need to
> listen to HAL for these, as rfkill switches are one big thing that NM
> does not handle now due to lack of a standard mechanism.

In userspace there are 2 ways to listen, either regularly check the sysfs entry
for the status. Or the prefered way listen to the input device that is created for
each key.

> In any case, any movement on rfkill interface/handling standardization
> is quite welcome :)

True, there are currently a lot of methods floating around. And a single way
to notify the user would be a nice idea. :)

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