Re: Wireless hotkey support

[Matthew Garrett <mjg59 srcf ucam org>]

On Wed, Jan 31, 2007 at 01:25:54PM -0500, Dan Williams wrote:

> Well, if we do actually want the "one key to rule them all" model, then
> wouldn't it be simpler to have a global wireless rf-enabled state in
> hal?  I think that's what you initially proposed before I misunderstood
> and asked for a signal-per-device.  NM would then bring down the devices
> if they weren't already hardware-disabled by some other mechanism.  But
> I don't think this model is decided yet.  We keep going back and forth
> on netdev about it.

Ok, that works.

> > 1) User hits wireless button
> > 2) Hal notices this event (somehow). Depending on its understanding of 
> > events, it places all controllable radios into either the on or off 
> > state.
> 
> What do you mean by "place"?  Does HAL actually talk to the driver or
> hardware and do the radio disable?  Or does it just modify it's internal
> per-device disabled state?

If userspace is catching the rfkill events, then in some cases something 
has to be responsible for actually disabling the radio in the driver. 
Given adequate driver support, that may just be as simple as downing the 
card (which will happen in the next stage), but (for example) ipw2200 
also exports an rf_kill switch in sysfs. I guess we should standardise 
on a mechanism.

> > Thinking about it, while rfkill provides a mechanism for tying together 
> > the interface between kill switches and hardware, does it provide a 
> > common interface for userspace to determine whether an interface has a 
> > working radio?
> 
> We need that too.  I had assumed that the _driver_ would be able to
> present that information via sysfs or something, which means HAL could
> pick it up or a script could poke /sys/class/net/wifi0/radio_state.

Right. The driver has that information, but currently it seems to be 
exposed in a driver-dependent way. We could put it under sysfs, or 
alternatively I guess it could be exposed via wext of cfg80211. 

> Basically, we really need to figure out whether it's rfkill-a-la-carte,
> or global disable before making more of these types of decisions.

Right. From a basic user experience, I'd lean towards global disable - 
it's easy to understand, behaves in a predictable way and is almost 
always what people want. We can provide more fine-grained control 
through a desktop-level UI if necessary.

-- 
Matthew Garrett | mjg59 srcf ucam org