From: "Németh Márton" <nm127@freemail.hu>
To: Richard Purdie <rpurdie@rpsys.net>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] LED updates
Date: Fri, 08 Feb 2008 08:03:33 +0100 [thread overview]
Message-ID: <47ABFEC5.8010206@freemail.hu> (raw)
In-Reply-To: <1202422388.9519.123.camel@dax.rpnet.com>
Richard Purdie wrote:
> On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote:
>> On Thu, 07 Feb 2008, Richard Purdie wrote:
>>> Márton Németh:
>>> leds: Add support for hardware accelerated LED flashing
>>> leds: hw acceleration for Clevo mail LED driver
>> This one has a loose end: when you call brightness_set on a led with
>> hardware flash acceleration, you will leave the trigger armed, BUT the led
>> won't blink anymore. That's just wrong.
>
> Agreed.
My only question is that do you know any LED hardware which can blink _and_
can set the brightness independently? If there would be such a LED I could
imagine that the brightness can be changed while the LED remains blinking at
some low frequency. For example a simple LED with brightness set possibility and
blinking directed by software is an example where the blinking and the brightness
setting are completely independent.
I agree, however, that if the brightness is set to LED_OFF, the trigger
should be also removed.
>> Either we should always remove *any* (hardware accelerated or not!) active
>> trigger when a write to brightness_set is done, or the stuff about "calling
>> brightness_set will disable the hardware accelerated blink" has to go.
>>
>> I personally prefer that we would always remove any active trigger if
>> brightness_set is to be called. IMHO, it is neater, and it is also the
>> least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL
>> triggers we have right now.
>
> Even without the hardware acceleration, a user write to set_brightness
> leaves any active trigger active and isn't really intuitive or right
> either.
>
>> Which one will be? If it is "remove any active trigger", I'd not mind
>> writing the patch.
next prev parent reply other threads:[~2008-02-08 7:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 10:35 [GIT PULL] LED updates Richard Purdie
2008-02-07 21:38 ` Henrique de Moraes Holschuh
2008-02-07 22:13 ` Richard Purdie
2008-02-07 23:23 ` [PATCH] leds: disable triggers on brightness set Henrique de Moraes Holschuh
2008-02-10 11:52 ` Németh Márton
2008-02-17 23:30 ` Richard Purdie
2008-02-18 1:59 ` Henrique de Moraes Holschuh
2008-02-08 7:03 ` Németh Márton [this message]
2008-02-08 11:20 ` [GIT PULL] LED updates Henrique de Moraes Holschuh
2008-02-10 11:52 ` Németh Márton
2008-03-16 18:18 ` Henrique de Moraes Holschuh
2008-03-16 19:29 ` Richard Purdie
2008-03-16 19:48 ` Henrique de Moraes Holschuh
2008-03-17 3:34 ` LED naming standard for LED class Henrique de Moraes Holschuh
2008-03-17 9:51 ` Richard Purdie
2008-03-18 3:35 ` Henrique de Moraes Holschuh
2008-03-18 4:55 ` Henrique de Moraes Holschuh
-- strict thread matches above, loose matches on Subject: below --
2007-10-11 21:38 [GIT PULL] LED updates Richard Purdie
2007-07-16 8:39 Richard Purdie
2007-02-15 22:18 Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47ABFEC5.8010206@freemail.hu \
--to=nm127@freemail.hu \
--cc=hmh@hmh.eng.br \
--cc=linux-kernel@vger.kernel.org \
--cc=rpurdie@rpsys.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.