On Thu, 2008-09-18 at 15:47 -0300, Henrique de Moraes Holschuh wrote:
> Passing rfkill state around using the input layer is broken, and caused real
> issues. That is what cannot be done, that is what was fixed in the new API.
> But that does not preclude, e.g., b43, from also exporting input events...
> *as long as* it is done correctly.
[...]
I don't get it.
We only have a few things to control:
* radio state for each device
and a few mechanisms:
1) mac80211-internal (TPC, ..., iwconfig txpower off)
2) per-hardware input button (soft)
3) per-hardware rfkill button (hard)
4) platform input buttons (soft)
5) platform rfkill buttons (hard)
b43, for example, 1, 2 and 3 (where connected, this is unknown to the
driver) and may live on a platform that also has 4, 5 is very unlikely.
The way I see it, we should have about this architecture:
input layer userspace mac80211 driver rfkill
2 ----------------->|
(a)----------------------------------->|
4 ----------------->| |
(b)<------------------|
|
+-------->(c)
(e)<-------(d)
|
+------------------->|
|
(f)<------------------------------------|
(a) synthesize rfkill state for each driver out of the various input
events you can get, depending on whether the platform button is
bluetooth, wlan, all, ...
(b) take rfkill state and transform it into conf.radio_enabled along
with the internal conf.radio_enabled state that mac80211 may decide
on based on iwconfig txpower off. assume that users know what
they're doing if they iwconfig txpower off, I think it's pretty
pointless to have in light of rfkill and for all I care we can
remove it
(c) take conf.radio_enabled and enable/disable radio
(d) notify mac80211 about _HARD_ rfkill state
(e) take that into account for internal state machine and report to
rfkill subsystem
(f) display to user
Driver only has to follow conf.radio_enabled and inform mac80211 of the
hard state.
Where's the flaw?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
