No. It changes the global state for WLAN rfkill switches, and then it
causes rfkill to call the toggle_radio(new global state) hooks of all
these switches. I know that's what you meant, but we better be explicit
about this.
There is NO notification of a key press, there is an explicit command to
change the radio switch state to an specific new state (it is not a
toggle command, even if the name of the hook is toggle_radio).
b43 should not be issuing KEY_WLAN events in this case. It should be
updating its rfkill->state (one of my patches add a proper way to do
this), but that's it. See below.
No wonder it does, it is a Bug From Hell to use the input layer to
*report* events that happened and were already handled. You use it to
*issue* events that *are still to be acted upon*, and that's only if you
are NOT the only one that will act upon them! Sometimes it is not
trivial at all to know in which side of the fence you are.
And here things get difficult. ipw2200 (or b43, or iwl*, etc) would
HAVE to know if its hardware rfkill input pin is supposed to be handled
as the canon way to know if rfkill is active or not, for example, not to
mention wheter it even makes sense for them to request that all other
radios change state (THAT is what issuing an input event means).
The simple, and IMHO any sane solution is to do the following:
1. Add a kernel notifier chain for b43, ipw*, iwl*, and other such
drivers to report any changes in their radio state (which is a product
of ALL their rfkill lines, software and hardware), and also changes in
their hardware rfkill input pins, using different events so that you
KNOW which ones are informing the world about input pin state changes,
and which one are just reports of a changed radio state.
2. NEVER issue input events from these drivers. At all. Just update the
rfkill switch state using rfkill_force_state, or let the pooling do it.
Then, we leave for userspace (hal + hal-info?) or a kernel platform
driver to decide if the kernel notification b43/ipw*/ilw*/etc issued
when it noticed its rfkill input pin changed state is to be made an
input event.
Better to have nothing but the platform firmware drivers issue such
input events. Have all other drivers issue notification events instead
(which are not input events), and have something else that can be model
specific decide which notification events are to be made input events.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
