Date: Wed, 18 Apr 2012 07:47:30 +0200
Message-ID: <s5hty0hoakt.wl%tiwai@suse.de> (sfid-20120418_074736_168929_B3A2AF6E)
From: Takashi Iwai <tiwai@suse.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Matt Chen <machen@suse.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	users@rt2x00.serialmonkey.com, ath9k-devel@lists.ath9k.org
Subject: Re: About rfkill racing issue.
In-Reply-To: <1334712476.3725.5.camel@jlt3.sipsolutions.net>
References: <CALx5=V_5XzAqddWRGzS4d-9MoHLV=abN2DOA-X7EtQ+78DBdzg@mail.gmail.com>
	<4F8C5816.8070402@sipsolutions.net>
	<s5h7gxfpjjh.wl%tiwai@suse.de>
	<1334712476.3725.5.camel@jlt3.sipsolutions.net>
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-wireless-owner@vger.kernel.org

At Tue, 17 Apr 2012 18:27:56 -0700,
Johannes Berg wrote:
> 
> Hi,
> 
> > The probblem we faced was that the hardware changes the hard rfkill
> > _and_ sends the WLAN key at the same time.  Since the rfkill input
> > handler toggles the soft rfkill at each WLAN key, if the rfkill
> > state at boot is like
> > 	hard: block
> > 	soft: unblock
> > then it'll change like
> > 	hard: unblock
> > 	soft: block
> > so the WLAN is never activated.
> 
> Heh, funky.
> 
> > In the end, we fixed the problem by disabling the keymap for WLAN
> > key.  But this is also assuming that BIOS does always rfkill.  If BIOS
> > behavior suddenly changes, you'll loose the rfkill behavior.
> 
> Yeah, this is kinda dumb. But really it needs to be encapsulated in the
> rfkill platform driver I think? Or is the WLAN key just a regular key on
> the keyboard? Maybe the platform driver on this platform could bind it
> and eat it?

In our case, it was a regular key on HP laptops.  I also thought of
the platform WMI or ACPI, but surprisingly it wasn't.

> > Also, another drawback is that now rfkill isn't triggered immediately
> > with WLAN key but it waits for some seconds until hard block is
> > polled.  Ideally, it'd be good if the rfkill hard state can be checked
> > immediately when WLAN key is issued (but without touching soft
> > block).
> 
> This has been talked about before I think, but I'm not sure it'd be good
> generic behaviour?

It really depends on the machine.
This rfkill-sync behavior assumes that the hard rfkill is really
implemented.  Otherwise it's broken.  So, it's not safe as a global
behavior, indeed.  It must be chosend very selectively.

Changing WLAN key behavior globally also has another problem, too.  If
user has an external USB "multimedia" keyboard with a WLAN key, it
can't work as expected.

Maybe it'd be good to have a new key code for rfkill-sync, and change
the key to it if BIOS does hard rfkill (either via module option, DMI
matching, whatever).  Then still the external keyboard can send the
normal WLAN key to toggle soft rfkill.


thanks,

Takashi