LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Németh Márton" <nm127@freemail.hu>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Purdie <rpurdie@rpsys.net>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] LED updates
Date: Sun, 10 Feb 2008 12:52:30 +0100	[thread overview]
Message-ID: <47AEE57E.9030000@freemail.hu> (raw)
In-Reply-To: <20080208112040.GA9485@khazad-dum.debian.net>

Henrique de Moraes Holschuh wrote:
> On Fri, 08 Feb 2008, Németh Márton wrote:
>> Richard Purdie wrote:
>>>>>       leds: Add support for hardware accelerated LED flashing
>>>> 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
> 
> Several, but none on laptops or other stuff that runs Linux.  That behaviour
> is not common on indicator LEDs.  I have seen standby LEDs on laptops which
> "blink" by slowly fading from full to off, and then back to full, though.
> 
>> 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.
> 
> Sure, it is perfectly possible.  I am not sure it is *desireable*, though.
> The way we have triggers work make what you describe impossible right now,
> the software triggers are LED_OFF:LED_FULL, not LED_OFF:old-brightness.
> 
> And so are the common hardware triggers on laptops, for that matter.
> 
> If we go and fix every trigger to use the current brightness (as long as it
> is non-zero) as the "turn LED on" trigger event, then the documentation has
> to be changed accordingly to do what you said above, and we would stop the
> trigger only by setting brightness to zero or by explicitly removing it.
> 
> I don't think it is worth the hassle, though.  But we better decide that
> *now*, because all this changing of the LED class ABI (even if it is, IMHO,
> a big improvement) is not a good idea.  We better do it all during the
> 2.6.25 cycle.

I investigated what would have to be changed if we decide that the
brightness and the blinking parameters can be set independently. There
are not much too change I think, please have a look at my next mail.

	Márton Németh

  reply	other threads:[~2008-02-10 11:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07 10:35 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     ` [GIT PULL] LED updates Németh Márton
2008-02-08 11:20       ` Henrique de Moraes Holschuh
2008-02-10 11:52         ` Németh Márton [this message]
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=47AEE57E.9030000@freemail.hu \
    --to=nm127@freemail.hu \
    --cc=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    --subject='Re: [GIT PULL] LED updates' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).