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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
