Date:	Sun, 02 Nov 2008 11:17:34 +0000
From:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	Matthew Garrett <mjg59@...f.ucam.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux acpi <linux-acpi@...r.kernel.org>
Subject: Re: eeepc-laptop rfkill, stupid question #4

Henrique de Moraes Holschuh wrote:
> On Fri, 31 Oct 2008, Alan Jenkins wrote:
>   
>>> Documentation/rfkill.txt implied otherwise
>>>       
>
> Then we need to make it more clear.
>
>   
>>>     You should:
>>>         - rfkill_allocate()
>>>         - modify rfkill fields (flags, name)
>>>         - modify state to the current hardware state (THIS IS THE ONLY TIME
>>>           YOU CAN ACCESS state DIRECTLY)
>>>         - rfkill_register()
>>>       
>
> At which point rfkill core will KICK your device to the state it wants it to
> be, so if you lied on the state, you are screwed. I mean it.
>
> You want rfkill_set_default(), and only because it is a platform driver
> storing state across shutdown.
>
>   
>>> Admittedly it doesn't say "and I promise not to gratuitously override
>>> the state on registration".  Buti t seems weird though, to override the
>>> value on registration 
>>>       
>
> No, it is EXACTLY what it should do.  It is setting policy for a class of
> switches (actually, controllers. Call it a switch and you confuse it with
> input devices).  It is not "enabling the radio" by default, it is setting
> the radio rfkill controllers to the same state that all other rfkill
> controllers on radios of that type currently are at.
>
> And there is rfkill_set_default() for *platform* drivers to influence that,
> when the platform has a better idea of the proper initial radio rfkill
> state.
>
>   
>> Ah, I see.  Wrong end - of course the *rfkill device* doesn't have
>> useful state.  The persistent state belongs to the *rfkill switch* - it
>> could even be a physical switch.
>>     
>
> Of course it has useful state. Set it to whatever the rfkill controller
> state really IS at that point.  And it HAS persistent state, but the core
> will govern it to match the system-wide policy.
>
>   
>> And now it's clear what was missing from the conversion to rfkill:
>>
>>     2. Input device switches (sources of EV_SW events) DO store their
>>     current state
>>     (so you *must* initialize it by issuing a gratuitous input layer
>>     event on
>>     driver start-up and also when resuming from sleep)
>>     
>
> No.
>
> You *ARE* to send gratuitous input layer events for SWITCHES quite often,
> e.g. on every call to the switche's connect() handler, and also often after
> system-wide stuff like resume (when state could have changed without you
> being able to notice it) because you *HAVE* to tell the input layer which is
> the initial/real state of the switch.  If this is not clear, the input layer
> needs some doc tweaking. Please feel free to send a patch to Dmitry.
>
> But that has nothing to do with the rfkill core.  You MUST NEVER try to
> change rfkill core state through the input layer from inside the kernel.
> NEVER.
>
> rfkill_input is NOT part of the rfkill core, and rfkill_input is the ONLY
> thing that cares about input events that match one of the "rfkill" input
> events.  And it *is* optional.
>   

Thanks for beating the clue into me. Part of the problem was I thought 
the "toggle wireless" key on my keyboard somehow counted as a "switch" 
input - but it doesn't, it's clearly just a normal "button" input.


Did you have any thoughts on the hibernation case? It's possible for the 
rfkill state to change while hibernated. You can boot into a different 
OS, or change it in the BIOS setup screen. At present the rfkill core 
overrides the change on resume.

Personally I don't care. Hibernation plus dual-boot or BIOS setup can 
already break in lots of exciting ways.

But I wonder if there are laptops where the BIOS handles rfkill by 
default, but the OS takes over on boot. Thinkpads? Then you could toggle 
the rfkill without going into the BIOS setup screen.

Actually, I think you could also do it if the resume kernel loads e.g. 
eeepc-laptop before it loads the hibernation image. That's the strongest 
argument I can think of.

Thanks
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists