Re: howto ignore rfkill switch

[Dan Williams <dcbw redhat com>]

On Tue, 2009-07-28 at 12:43 +0200, Marcel Holtmann wrote:
> Hi Brian,
> 
> > >> rfkill is *not* the mechanism to disable a specific card completely.
> > > 
> > > Yes it is.
> > > 
> > > A hardware switch is great. It is so more intuitive than any software
> > > interface, since it just looks like the good old ON/OFF button that
> > > everybody understands since they were three years old. By making one
> > > single button act on multiple unrelated devices you try to make the
> > > machine too clever and leave the fundamental ON/OFF analogy behind.
> > 
> > It might be great if you actually have a hardware switch, a lot of
> > machines do not. My laptop uses Fn-F2 and that disables Wi-Fi and
> > Bluetooth simultaneously but not by cutting the power to them or by
> > toggling an enable line to the radios. It does it by some sort of
> > software mechanism.
> > 
> > 
> > > This ON/OFF analogy is so fundamental that most users do not even
> > > suspect it is an analogy! They simply think that the button is actually
> > > hard-wired to the device. "Cool, a hardware button!  Finally something
> > > simple and reliable to switch off all this complex and buggy software!".
> > 
> > Or "Damn! Why the hell can't I switch off my WiFi and leave my Bluetooth
> > active so I can use my mouse?"
> 
> that is actually the fault of the old RFKILL input stuff in the kernel.
> It was wrong and we will be moving this to userspace. So you can
> actually toggle between it with visual feedback to the user.
> 
> Let me repeat, every RFKILL before the 2.6.31 kernel was a complete
> cluster-fuck, heavily complicated and just plain wrong. Check the
> linux-wireless mailing list archive if you have a day or so. There are
> quite a few posts about it :)

And this is most of the reason why people have problems with NM's rfkill
support.  The reason why NM used global rfkill was that it was simply
*impossible* to tie a specific rfkill switch to a specific wifi card
with kernels before 2.6.31.  It's still difficult, but no longer
impossible.

Dan