Messages in this thread | | | Date | Sat, 12 Apr 2008 17:36:01 -0300 | From | Henrique de Moraes Holschuh <> | Subject | Re: [PATCH 3/8] rfkill: handle KEY_RADIO and SW_RADIO events |
| |
On Sat, 12 Apr 2008, Carlos Corbacho wrote: > Although the current wireless driver implementations of rfkill/ input polling > have been causing me a bit of a headache lately, with no nice solution in > site, because of the following (b43 does this, but I suspect rt2x00 may also > do the same, so it's a slightly more generic problem). Now, I have a patch > locally to add rfkill support to acer-wmi, but still keep seeing the > following: > > 1) acer-wmi loads > 2) Press KEY_WLAN > 3) rfkill-input notifies all registered KEY_WLAN rfkill drivers that KEY_WLAN > has been pressed.
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).
> 4) acer-wmi toggles the wireless radio state > 5) b43 notices this state change because of it's polling, then sends a > KEY_WLAN event (even though b43 knows it can't control the radio on my > laptop)
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.
> 6) Goto 3. > > And this continues in a loop. Removing the offending input_report_key() lines > in the wireless driver stops this.
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.
> Ideally, I think we are going to need some way of saying that platform > firmware level drivers (e.g. acer-wmi, thinkpad-acpi, etc) take priority over > the wireless drivers, and that the drivers should _not_ send out these > KEY_WLAN events if one of acer-wmi, etc are loaded (or find some other nice > way of handling this).
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
| |