Re: does/can networkmanager ever set rfkill?

[Dan Williams <dcbw redhat com>]

On Thu, 2010-02-25 at 16:22 -0500, Paul Fox wrote:
> dan wrote:
>  > On Thu, 2010-02-25 at 15:42 -0500, Paul Fox wrote:
>  > > i'm revisiting our ability to kill power to the wireless device
>  > > for the XO-1.5 laptop.  this time around, we're using rfkill to
>  > > do so.  (the XO-1 used a private mechanism.) since there's no
>  > > dedicated rfkill button, we need to invoke rfkill from a UI.
>  > > 
>  > > i was sort of expecting/hoping that NetworkManager could be used
>  > > to invoke rfkill, since that would be portable, and provide
>  > > persistence for the setting all at once.  but all i can find are
>  > > lots of ways in which NM reacts to rfkill events, and nothing
>  > > regarding it actually doing an rfkill block/unblock itself.
>  > > 
>  > > is this correct?  or have i overlooked something?  can NM, and the
>  > > applet, be used as a soft rfkill switch?
>  > 
>  > Is XO 1.5 rfkill implemented via the rfkill subsystem?  If not, it
> 
> yes, it is.
> 
>  > should be.  The NM enable/disable wireless mechanism can probably
>  > finally be updated to take advantage of /dev/rfkill too, which would
>  > then fix your issue.  It's something we need to do anyway.
> 
> that would be great.
> 
>  > 
>  > Currently when told to "disable wireless" NM just take the wifi device
>  > down, in which state it is assumed that the driver will place the devce
>  > into low-power mode.  NM does *listen* for rfkill events, and changes
>  > various D-Bus properties (WirelessEnabled, WirelessHardwareEnabled)
>  > based on the rfkill state.
> 
> yes -- all of that's what got my hopes up. :-)  i assume this
> means that if we implement a UI that manipulates rfkill, we don't
> actually need to communicate with NM directly, correct?  from
> experimentation it seems to do all the right stuff based on the rfkill
> event. 

For NM 0.8, yes, as long as your driver is correctly implemented.  NM
will get the uevents from udev and do the right thing without any extra
effort on your part.

For NM 0.7, HAL is still used for rfkill and NM polls the HAL objects
periodically for rfkill status.  So if you're still using NM 0.7 in
these builds, you may also need to make a few "callout" scripts that
check the value of /sys/class/rfkill/rfkill0/state in response to the
HAL callout.

Dan