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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
