Re: Wireless hotkey support

[Matthew Garrett <mjg59 srcf ucam org>]

On Wed, Jan 31, 2007 at 10:11:56AM -0500, Dan Williams wrote:
> On Wed, 2007-01-31 at 08:32 +0000, Matthew Garrett wrote:
> > I've just submitted a patch to hal that should result in hitting a 
> > wireless hotkey sending an event over dbus. The obvious next step is 
> 
> How does this jive with Ivo van Doorn's rfkill infrastructure that's
> just been updated on netdev?  Or is this the HAL -> client part, which
> will simply be triggered by whatever Ivo comes up with?

rfkill works in two ways, depending on whether or not an application has 
opened the input device it provides. In the "default" mode, hitting the 
rfkill switch will toggle the radio state directly, whereas if the input 
device is open (which is what I'd imagine to be the default in a 
hal-based system) it'll send a signal out to userspace instead. In some 
cases, the radio will already have been brought down, but otherwise we 
can then leave it to the policy daemon (n-m in this case). 

> > that n-m should catch this and toggle the wireless state. However, I'm 
> > not entirely clear what level this should be done at - the daemon or the 
> > applet? I'm leaning towards the daemon, since it's a system-wide event 
> > and should ideally work even if there's no user logged in. Any other 
> > opinions?
> 
> Definitely the daemon.  If the radio is dead, there's absolutely no
> reason that NM shouldn't know about it _now_, so that it can clean up.

Makes sense.

> Furthermore, is this a per-device signal?  Because if it's not, it
> should be; the rfkill infrastructure may or may not make the rfkill
> signals be per-device, but HAL should certainly send out one signal for
> each device whos radio is now dead.

In some cases, the wireless key is simply a key on the keyboard. 
Logically I guess we should tie that to any minipci card, but telling 
the difference between an internal minipci card and a cardbus one (which 
may have the same chipset) isn't going to be trivial. My instinct was 
that the wireless key would be considered to be a global thing ("I don't 
want wireless") rather than controlling an individual device, regardless 
of how it's wired internally.

> > Secondly, there needs to be some mechanism for keeping track of the 
> > hardware state. While some buttons are implemented in software, others 
> > are in hardware. It's important that we not get into a state where 
> > hitting the hotkey disables the radio while causing nm to bring up the 
> > interface, or vice-versa. Right now, different drivers seem to expose 
> > this information in different ways, so presumably we want to look at 
> > implementing this in hal as well?
> 
> No, this needs to be left to the rfkill patches.  The _driver_ needs to
> maintain the rfkill state if the button is just another one-state
> keyboard button and does not actually have two states.  The driver must
> know when the radio is disabled, and that should be the source of the
> information that HAL (eventually) uses to send out the signals for
> rfkill to the HAL clients.  The driver needs to the be the _one_ stop
> shop for device state.

No, that doesn't work for all cases. On my machine, for example, the 
wireless key doesn't alter the radio state at all. In that situation, 
it's network-manager that's going to get to decide what state to put the 
hardware in.

-- 
Matthew Garrett | mjg59 srcf ucam org