On Thu, Jun 22, 2006 at 05:55:46PM +0200, Jiri Benc wrote:
> On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> > With this approach more buttons can be registered,
> > it includes the optional field to report an update of the key status
> > to the driver that registered it, and it supports for non-polling keys.
>
> I think this is not specific to networking anymore, so it should go to
> lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov.
>
> Regarding rfkill button, I talked about that with Vojtech Pavlik (Cc:ed)
> and he suggests this solution:
>
> - driver is responsible for turning on/off radio when the input device
> is not opened;
> - when something opens the input device, it receives input events and
> gets responsible to turn on/off the radio (by ioctl or putting the
> network interfaces up/down).
>
> This is of course not possible for all hardware, but it gives the most
> flexibility while keeping the possibility to switch of the radio without
> userspace support.
Let me elaborate a little bit on the possible implementation:
1) 802.11 card drivers will implement an input device for each card in
the system that has a user-controlled RF-Kill button or switch.
2) 802.11 card drivers will implement an interface to enable/disable the
radio, be it through a call, ioctl, or whatever, that is accessible from
both the kernel and userspace.
3) ACPI buttons drivers, and keyboard drivers will generate KEY_RFKILL
on machines where RF-Kill keys are reported using ACPI events or
keyboard scancodes.
3) A rfkill.ko input handler module will be implemented, that listens to
the SW_RFKILL and KEY_RFKILL events from all devices in the system, and
will enable/disable radios on all 802.11 devices in the system.
The above will make the RF-Kill button work under all real scenarios as
user expects - it will enable/disable the radio. In the case where a
user has an additional PCMCIA card, both the radios will be disabled by
presing the RF-Kill button, which is arguably what the user expects.
Even BlueTooth or other RF technologies (CDMA, EDGE) can hook into this
mechanism.
4) When userspace wants to take over the control over RF-Kill, and start
additional services based on that, it can open the input devices to get
the state of the buttons/switches, AND it can issue the EVIOCGRAB
ioctl() to prevent the rfkill.ko and any other handlers from getting the
events.
This allows simple implementation of dbus notifications and
NetworkManager-style configuration of network interfaces.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
