Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn

[Ivo van Doorn <ivdoorn@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3088 bytes --]

Hi,

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

So basicly 1 input device for every single wireless driver that implements
the RF-Kill button?
Is there any particular reason for not using 1 input device shared by all?

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

Userspace could switch off the radio by using the txpower ioctl of
ifdown/ifup. Or should an approach call be implemented?

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

Why both an input and ACPI event?
With ACPI restricted to x86 only, wouldn't a more generic approach be desired?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]