On Mon, 23 Jun 2008, Dmitry Torokhov wrote: > On Mon, Jun 23, 2008 at 02:22:07AM -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 22 Jun 2008, Fabien Crespel wrote: > > > rfkill_epo() doesn't change the current_state of the tasks, and the > > > various calls to rfkill_schedule_set(..., RFKILL_STATE_ON) don't work if > > > the last current_state stored was already RFKILL_STATE_ON. > > > > > > Anyway, the whole current_state thing seems completely useless and a > > > source of problems in rfkill-input, since state comparison is already > > > done in rfkill, and rfkill-input is more than likely to become out of > > > sync with the real state. > > Real state of what? The state of rfkill-input represents desired > (target) state of a group of RF switches of certain type (all WIFI or > all Bluetooth, etc) and may indeed be different from the state of > individual transmitter. Indeed. rfkill-input takes care of what I call "global state (per rfkill type)". We don't export that to userspace yet, the only way to interact with them is through input events right now. This will change, eventually. That said, there is no need to try to avoid extra calls to rfkill_switch_all, which AFAIK is all current_state is good for. I tested Fabien's patch here, and it does seem to work well. I added some guards to EPO so that it just ignores any attempts to queue rfkill_switch_all calls while a rfkill_epo call is queued, as well. > > > Therefore I propose this additional patch to remove current_state > > > completely from rfkill-input. > > > > I would like to get rid of it, but I need some sleep before I can think > > clearly about this issue. > > I think the best solution for now would be to add 'force' argument to > rfkill_switch_all that would override rfkill->user_claim. No, rfkill-input is not to override rfkill->user_claim except for EPO. Even if we added a force parameter to rfkill_switch_all, rfkill-input wouldn't be able to use it (except in the EPO path, that has a better helper to use anyway: rfkill_epo()). I fixed the whole EPO issue already, btw. I tried with Fabien's patch, and on top of it I applied a modified version of the EPO patch that calls rfkill_epo through the generic work queue and ignores other attempts to queue rfkill_switch_all while rfkill_epo hasn't run yet (on the grounds that rfkill_epo would override them anyway, and that when in doubt of what should be happening because we got a bunch of confusing events all piled up, we want EPO to win). I am just waiting for Fabien's signed-off-by line, so that I can push v3 of the patchset with the bug fixes. I am also looking at a way to make rfkill-input restore the previous global states when it receives an SW_RFKILL_ALL ON sometime after an EPO. That's how I'd prefer it to act (so I will make it selectable, and you guys tell me what the default should be). -- "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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
