Re: Question on rfkill double block

[Fabien Crespel <fabien@crespel.net>]

Dan Williams wrote:
> But if the HW block is on, NM doesn't care about softblock because you
> can't use the radio anyway.  If the HW switch is unblocked, NM will
> un-SW-block the radio anyway, since HW-unblock is definitely a
> user-initiated option and signals user intent to unblock the radio
> irregardless of SW block state from something else.

Removing the SW switch after the user unblocks the HW switch seems wrong to me: 
HW-unblock doesn't necessarily mean the user wants to unblock WLAN if it was 
SW-blocked before (which is most likely the user's choice).

Consider the following situation:
- the computer has a WLAN device and Bluetooth device
- both devices can be HW-blocked with a single physical switch
- each device can be toggled with a key

With the following scenario:
- I (the user) don't want to use WLAN for whatever reason (like using a wired 
network, or to save energy)
- I want to have Bluetooth enabled for my wireless mouse
- I temporarily enable the HW switch (because I don't need the mouse anymore, or 
to let someone else use it on his/her own computer)
- A bit later, I want to use Bluetooth again and disable the HW switch
- Both Bluetooth and WLAN would now be enabled

This can be annoying, especially if NM connects to a wireless network 
automatically. It would consume energy needlessly, or break the network config if 
both the wired and wireless connections are configured for the same IP.

So generally, I would say that assuming to know what the user wants is dangerous, 
as it can result in doing something against his will. If the user wants to enable 
WLAN, there is a key for it.

Also note that this would still happen without NM but with rfkill-input, since 
currently it doesn't restore the previous state when the HW switch is disabled. 
It just unblocks the device (Andy posted about it half an hour ago).
Any news on this, Henrique? I think you talked about it some time ago, and with 
the new double block enum, it should be easier to know the previous state.

- Fabien.