On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote:
>
> (Actually, "::wifi" is super confusing, I'd expect that to be a led
> that blinks when wifi is active.)
Agree with that, yeah, that'd be confusing.
> Well... "airplane" is quite confusing. I'd we use "rfkill" for
> disabling radios, and
On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote:
> On 13 June 2016 at 17:01, Pavel Machek wrote:
> > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
> >> On 13 June 2016 at 15:00, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> >> > João, that means you should send a patch to add the
On 13 June 2016 at 17:01, Pavel Machek wrote:
> On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
>> On 13 June 2016 at 15:00, Pavel Machek wrote:
>> > Hi!
>> >
>> >> > João, that means you should send a patch to add the ::rfkill suffix.
>> >> >
>> >>
>> >> IMO "airplane" (or maybe "airpla
On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
> On 13 June 2016 at 15:00, Pavel Machek wrote:
> > Hi!
> >
> >> > João, that means you should send a patch to add the ::rfkill suffix.
> >> >
> >>
> >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
> >> reflects the la
On 13 June 2016 at 15:00, Pavel Machek wrote:
> Hi!
>
>> > João, that means you should send a patch to add the ::rfkill suffix.
>> >
>>
>> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
>> reflects the label on the machine's chassis. I'll name it
>> "asus-wireless::airplane" a
Hi!
> > João, that means you should send a patch to add the ::rfkill suffix.
> >
>
> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
> reflects the label on the machine's chassis. I'll name it
> "asus-wireless::airplane" and send this through platform-drivers-x86,
> as this is
On 9 June 2016 at 08:43, Johannes Berg wrote:
> On Thu, 2016-05-19 at 09:16 +0200, Pavel Machek wrote:
>
(...)
>> LED
>> subsystem seems to use suffix of LED name to do that. So if we
>> standartize, lets say "::rfkill" suffix for this, it should work and
>> follow existing practice.
> [...]
>>
On Thu, 2016-05-19 at 09:16 +0200, Pavel Machek wrote:
> > In the original situation, without these patches, userspace has to
> > have a list of all LEDs that are supposed to indicate airplane
> > mode.
> Well, that's situation for many LEDs.
That doesn't make it a *good* situation though.
> > W
On Thu 2016-05-12 11:32:52, Johannes Berg wrote:
> On Wed, 2016-05-04 at 09:29 +0200, Pavel Machek wrote:
> >
> > If userspace wants to control the manually, it can do just that --
> > control it manually. There should not be a need to "override the
> > default policy".
>
> I'm still not buying t
On Wed, 2016-05-04 at 09:29 +0200, Pavel Machek wrote:
>
> If userspace wants to control the manually, it can do just that --
> control it manually. There should not be a need to "override the
> default policy".
I'm still not buying this.
In the original situation, without these patches, userspa
Hi!
> This creates a new LED trigger to be used by platform drivers as a
> default trigger for airplane-mode indicator LEDs.
>
> By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
> for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL
> when the changing the
From: João Paulo Rechi Vita
This creates a new LED trigger to be used by platform drivers as a
default trigger for airplane-mode indicator LEDs.
By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL
when the
12 matches
Mail list logo
