LKML Archive on
help / color / mirror / Atom feed
From: "Németh Márton" <>
To: Richard Purdie <>
Cc: Pavel Machek <>,
	Dmitry Torokhov <>,,
Subject: Re: [PATCH] input: extend EV_LED
Date: Sun, 18 Feb 2007 08:45:00 +0100 (CET)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1171580944.5839.38.camel@localhost.localdomain>

On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote:
> On Thu, 15 Feb 2007, Richard Purdie wrote:
> > This has been discussed in several places several times.
The problem
> > with hardware accelerated flashing is that you're are
often limited to
> > certain constraints (this case being no exception) and
indicating what
> > these are to userspace in a generic fashion is difficult.
> The hability to blinking at one rate is *very* common on
laptops.  Blinking
> at a few discrete rates is also common enough.  They
should be supported in
> a generic way.
> [...]
> Here's a suggestion for a simple, non-overengineered
interface: a "blink"
> attribute (on/off) for leds which can hardware-blink. 
Only one blink
> frequency is common enough that this attribute by itself
is very useful
> (e.g. it is all a ThinkPad and most WiFi/network card leds
> For hardware-blink leds with various frequencies, there is
the typical way
> to provide such things: give us a RO
blink_available_frequencies attribute
> which says which discrete frequencies are allowed (space
separated), and a
> RW blink_frequency attribute to set the frequency.  If
instead of
> blink_available_frequencies, the driver provides RO
blink_frequency_min and
> _max attributes, then it means it can blink on that range
of freqs.
> That is simple enough to implement and use, and generic
enough.  You just
> need to set in stone if you want the freq in Hz, or a
submultiple.  You can
> even implement an optional "blink" software emulation that
drivers can hook
> into for systems where the driver *knows* that led access
is fast, but there
> is no hardware blinking emulation.

A blinking led is basically a PWM (Pulse Width Modulation)
signal. A PWM signal has three different attribute. The
first one is the amplitude, this attribute is already
provided by the led subsystem as "brightness". There are two
more attributes, which are the frequency [Hz] and the duty
cycle [%], or the on-time [ms] and off-time [ms].

The frequency [Hz] and duty cycle [%] parameters has the
problem, that if we are limited to integers, it is not
possible to express slower blinks than 1Hz. We could also
use [mHz] (milli-Hertz), but it is not very common unit.

The on-time [ms] and off-time [ms] seems to be easier to
handle (and this is also easier to simulate from software if
ever needed). An RO attribute could be introduced:
'pwm_available', which can contain parameter pairs separated
by space, and the new parameter pair is in new line. An RW
attribute 'pwm' could accept a parameter pair separated by

A range could be also given in 'pwm_available', like this:
'500-1000 500-1000'. This has the limitation that if there
is a hardware which can blink a LED in differet freqencies,
but only with fixed 50% duty cycle, the on-time off-time
pair cannot express this range easily.

My real-world example would be my Clevo D4J (D410J)
notebook's mail led. It has three known state: off, PWM at
1Hz (50%), PWM at 0.5Hz (50%). In case the on-time [ms]
off-time [ms] parameter pairs are used:

$ cat pwm_available
500 500
1000 1000

What is your opinion?
Is there more real-world hardware accelerated blinking LED
parameter examples?


Kedvező tandíjak, különleges kedvezmények és magas szintű szolgáltatások. 
Ez az Educomm online nyelviskola és az egyedülálló EDUCATOR. Kattints ide!,1,6022,131839,203066/click.prm

  parent reply	other threads:[~2007-02-18  7:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-11 10:02 Németh Márton
2007-02-12 18:31 ` Dmitry Torokhov
2007-02-14 19:06   ` Németh Márton
2007-02-14 19:49     ` Dmitry Torokhov
2007-02-14 23:51       ` Németh Márton
2007-02-15 17:40       ` Pavel Machek
2007-02-15 22:47         ` Németh Márton
2007-02-15 23:09           ` Richard Purdie
2007-02-15 23:24             ` Pavel Machek
2007-02-15 23:36               ` Richard Purdie
2007-02-16  3:12             ` Henrique de Moraes Holschuh
2007-02-18 11:05               ` Richard Purdie
2007-02-18 14:42                 ` Henrique de Moraes Holschuh
2007-02-18  7:45             ` Németh Márton [this message]
2007-02-18  8:07               ` Willy Tarreau
2007-02-18 11:12               ` Richard Purdie
2007-02-16 14:04           ` Pavel Machek

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] input: extend EV_LED' \

* 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).