On Wed, 2016-02-24 at 13:14 +0100, Pavel Machek wrote:
>
> Why would it need to? It could look at default triggers for the led
> if it really wanted to.
And then it needs to change them; if anything goes wrong error recovery
is practically impossible since the trigger information is lost
On Wed 2016-02-24 12:01:37, Johannes Berg wrote:
> On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote:
>
> > If you want different trigger, implement different trigger. If you
> > want to indicate all but wifi, implement all but wifi, and then
> > userspace can select it by writing trigger
On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote:
> If you want different trigger, implement different trigger. If you
> want to indicate all but wifi, implement all but wifi, and then
> userspace can select it by writing trigger name.
This is still mostly a strawman, since userspace
On Tue, 2016-02-23 at 22:45 +0100, Pavel Machek wrote:
> Well "the airplane mode" is well defined. It means no intentional
> transmitting at radio frequencies.
>
> The fact that you are allowed to use WIFI on certain flights does not
> change anything.
Nope, not that simple. Pick up any
On Tue 2016-02-23 21:55:14, Johannes Berg wrote:
> On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote:
>
> > So... you add LED trigger to display the state of the airplane
> > mode. Ok, why not.
>
> Yes. However, consider that "the airplane mode" isn't a well-defined
> concept; some systems
On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote:
> So... you add LED trigger to display the state of the airplane
> mode. Ok, why not.
Yes. However, consider that "the airplane mode" isn't a well-defined
concept; some systems may want to light up that LED even when wifi is
still enabled,
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
