On Sat, 2009-12-05 at 18:12 -0200, Henrique de Moraes Holschuh wrote: > 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. Except that it is also sent internally in rfkill when the input device is registered by rfkill_start at input.c:252 (without any request from the individual driver afaict - other than support for EV_SW), which is where the problem is happening. > 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. So states being preserved across reboots is not considered part of the common use case? I can live with that, although it is frustrating. >> 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. Yep, it's a 1-liner fix. I'll work on it. Kevin ------------------------------------------------------------------------------ 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
