On 8 February 2016 at 11:11, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote: >> Provide an interface for the airplane-mode indicator be controlled >> from >> userspace. User has to first acquire the control through >> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole >> time >> it wants to be in control of the indicator. Closing the fd or using >> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy. >> >> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE >> operation is used, passing the value on "struct rfkill_event.soft". >> If >> the caller has not acquired the airplane-mode control beforehand, the >> operation fails. > > I'd like to clarify a bit, so tell me if I'm correct or not. Using > RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device > state. It's just an indicator with no relationship to any of the > registered rfkill switches, right? > Yes, that's correct, and it is the intended behavior. > I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't also > softblock all switches, otherwise you can set airplane mode all day > long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually enable > airplane mode at all? > The idea behind it is to just provide the mechanism for userspace to decide what exactly being in airplane mode means, so it would set/unset the indicator in the right moment. -- João Paulo Rechi Vita http://about.me/jprvita -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
