On Sat, 05 Dec 2009, Kevin Locke wrote: > Rfkill pretends that the master switch was set in its current position > at startup by using an EV_SW event on devices that support them. So Actually, no, rfkill doesn't pretend anything. The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi) *push* EV_SW events to rfkill with the current state. The input layer does level-to-edge conversion, but that cannot be done at driver load (we don't know the previous state), so in practice, you will tell the rfkill core that the rfkill switch has just been enabled/disabled when any such module loads. This is why you see rfkill EV_SW SW_RFKILL_ALL-related activity when you rmmod and then modprobe thinkpad-acpi back again. Fixing this is possible, but quite troublesome (we need to register an input device signature permanently in the rfkill core, and remember it across input device attach/detach, and do the right thing if it attaches twice because there are two such devices in the system, etc). In the most common use case (modules are loaded at boot and left alone after that) it causes no problem, so I don't think it will get fixed anytime soon. But if it is pestering you enough to write the code, you could ask the rfkill maintainer if he would accept such a patch (feel free to have me in the Cc). > when master_switch_mode=0 everything gets set to blocked, when > master_switch_mode=2 everything gets set to unblocked. This is by > design (and 2 is the default). The problem is that > master_switch_mode=1 does not behave well at all and default_state is > ignored. > The reason that master_switch_mode=1 is broken is that when a new > input device is registered, the rfkill_handler specifies rfkill_start > to be called for the new handle, which schedules an > rfkill_restore_states to be called before rfkill_eop is ever called. > So the 0-initialized (unblocked) save state is loaded for all devices. master_switch_mode=1 should set it to whatever the default state is (there's a module parameter to set that, I use "1" since I want radios blocked by default) if no epo ever happened (i.e. it doesn't have a state to go back to), or maybe do nothing at all if epo never happened before. Note: I didn't check what it is doing right now. If it is broken, I think a patch fixing this would be accepted by the rfkill maintainer. > initialized). However, this doesn't provide a way for thinkpad_acpi > to inform rfkill what the default state of each type should really be. We inform the core about the default state for the rfkill devices managed by thinkpad-acpi. It used to take that information from the first device of a given type that registers itself to be also the default for that type. I don't know if it still does that. > So, unless I am overlooking something, I think rfkill needs a new API > call to set the default state for each type of radio that tpacpi could > use before this bug can be fixed. It used to have one. If it still does have one, it is a bug that we're not using it. However, it now knows when a device is of the "persistent" type, and it could well set the global state for a type to the state of the first device of that type that gets registered *if* that device is "persistent". After it happens for the first type (or if the first device of a given type that registers itself is not persistent), the oportunity is gone and whatever device that registers itself is to be brought to the same state of the other devices of the same type (unless hardware blocked, etc). -- "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 ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
