On Wed, 02 Jul 2008, Zhu Yi wrote: > It doesn't say what to do if both the hardware and software rfkill lines > are active when RFKILL_STATE_UNBLOCKED is asked. Should we deactivate > the software rfkill in this case? Otherwise below usage won't turn on > the radio: Well, we allow double-blocking to make sure the radio isn't unblocked by mistake. The bias in rfkill is to block, as that is safer. The issue is that if we get a RFKILL_STATE_UNBLOCKED request, and we are at RFKILL_STATE_HARD_BLOCKED, we need to return an error (we can't set the requested state). But since we returned an error, should we do the best we can, or should we do nothing? I am really not sure what would be better: to remove the double-blocking while still returning an error, or to leave the radio as is (be it double-blocked or just blocked by the hardware rfkill line) and return an error. Both would work just fine as far as the rfkill class goes, it wouldn't get confused by either as far as I can tell (*as long as an error is returned!*). But we really should pick one of the two, and document that IMHO. My best guess is that doing a half-unblock would be less confusing to the user, but we can ask the userspace GUI people about it ;-) Dan? > hardware rfkill activate > software rfkill activate > RFKILL_STATE_UNBLOCKED request > hardware rfkill deactivate > > Furthermore, if we permit double block, what should get_state() return? get_state() returns RFKILL_STATE_HARD_BLOCKED when any hardware rfkill lines are active. If ALL hardware rfkill lines are inactive, it will return RFKILL_STATE_SOFT_BLOCKED if any software rfkill lines are ative. And if EVERY rfkill line is inactive, it returns RFKILL_STATE_UNBLOCKED. This makes sense, as you are basically stuck without being able to go anywere when in RFKILL_STATE_HARD_BLOCKED, until something external changes the hardware rfkill lines. > Shouldn't rfkill_state ???be bitmap instead of enum? We could do that, too. But a bitmap would cause trouble due to the ABI we inherited from the rfkill in the stable kernels, so it would be cleaner to just add a fourth state (RFKILL_STATE_DOUBLE_BLOCKED). However, I am pretty certain we will find firmware (hardware is less likely to be this stupid) that has erratic behaviour when RFKILL_STATE_HARD_BLOCKED (and thus you don't really know if you managed to double-block or remove a double-block). In fact, that's the kind of crap I am used to fight in thinkpad-acpi, although I sure hope thinkpads don't have this particular quirk. So, I pose this question: Four states would allow us to tell the user the radio is JUST hardware-killed or JUST software-killed for some hardware, but does THAT enhance the user experience in any way? Do GUIs really need that detail? If the answer is "yes, it is good, let's do it", I can certainly try to cook up a patch. But if it is "no, it wouldn't do much for the user", or if the answer is too uncertain, I don't think we should do it. -- "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
