On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote: > Ok, so it is the rfkill-input stuff (that is now part of the rfkill core) > that is showing the problem (the bug might be elsewhere). We need to track > the state of the rfkill input device to know what's broken, then. OK. I think I have a pretty good understanding of what is going on now. 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 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. default_state can be fixed by initializing the saved state to the default state in rfkill_init (currently only the current state is initialized). However, this doesn't provide a way for thinkpad_acpi to inform rfkill what the default state of each type should really be. 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. If this analysis seems correct, I can try taking this up with the rfkill maintainers. -- Cheers, | kevin@xxxxxxxxxxxxxxx | JIM: kevinoid@xxxxxxxxxx Kevin | http://kevinlocke.name | IRC: kevinoid on freenode ------------------------------------------------------------------------------ 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
