On Sat, 05 Dec 2009, Kevin Locke wrote: > 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. Well, thinking about it, it is clear rfkill has no choice but to do that, as it has to handle hotplugging. I have fixed thinkpad-acpi to not issue initial events, and sync the inputdev "sw" bitmap directly. I have also a patch to add an API to do it properly to the input layer, which I will submit after the quick-and-dirty fix hits mainline (otherwise experience tells me it will cause headaches). I will post the changes here, for your testing. Maybe they won't fix everything, but they should help. > > 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. No, state *MUST* be preserved across reboots. What is not first-priority is to preserve state across thinkpad-acpi module reloads *when one DOES NOT reload the rfkill core*. A reboot or shutdown will also reload the rfkill core. If state preservation across shutdown/reboot is broken, it is something I will do all I can to fix. BTW: I will have to do state preservation the hard way for suspend/resume, the firmware is not cooperating on some thinkpads. I will prepare a further fix for the driver on top of the rfkill suspend/resume fix I already sent to linux-acpi. -- "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
