Re: Wireless hotkey support

[Dan Williams <dcbw redhat com>]

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?

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

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.

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

dan