Re: howto ignore rfkill switch

[Cedric Pradalier <cedric pradalier gmail com>]

On Mon, Jul 27, 2009 at 8:15 PM, Dan Williams <dcbw redhat com> wrote:

On Mon, 2009-07-27 at 20:02 +0200, Marcel Holtmann wrote:
> Hi Dan,
>
> > > Well, actually in the case of the OP, the switch has nothing to do
> > > with the PCMCIA card, and the card is still on, available and
> > > configurable by hand (iwconfig, ifconfig) when the switch is off. It
> > > is just NM that decides to disable all wireless possibility even if
> > > the switch concerns only the internal card.
> >
> > You've flipped the rfkill switch, thus you do not want to use wifi.  If
> > you do actually want to use wifi, there are other, better mechanisms to
> > just kill the card you don't want to use.  rfkill is *not* the mechanism
> > to disable a specific card completely.
>
> it actually is the right way to kill a specific WiFi card. It is not
> that useful if you have platform switches in your system that interact
> with hotplug, but RFKILL works on a per device and all devices basis. At
> least the re-write coming with 2.6.31 does this correctly.

Most of the people trying to use two cards are doing so because they
never want to use the internal one.  There are better ways of handling
this (blacklisting, etc) *at this time* than using rfkill.  Yes, 2.6.31
will work better here.  Half the reason NM elected to use global rfkill
was because the kernel interfaces sucked up until now.

Dan

> The hardware RFKILL button/switch on your laptop needs to be tied into a
> userspace policy to decide what to do with external devices. That is out
> of the scope of the Linux kernel.
>
> Regards
>
> Marcel
>
>

Just to remind the original post. We don't WANT to use the RFKILL switch. It is somehow dodgy on this laptop and it switches itself on and off when you move the screen or put your hands on the palm rest. 
The original question was: is it possible to make NM ignore it? because we KNOW it is not a reliable indication of what the user wants to do.

Anyway, thanks for all the useful answers so far on this thread. 

-- 
Cedric Pradalier