lkml.org 
[lkml]   [2007]   [Feb]   [18]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 18 Feb 2007 09:07:15 +0100
FromWilly Tarreau <>
SubjectRe: [PATCH] input: extend EV_LED
On Sun, Feb 18, 2007 at 08:45:00AM +0100, Németh Márton wrote:
> > 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> need).> > > > 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
> space.> > 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?

Maybe you should consider that if there's only one parameter,
it implies both on- and off- times, leading to a duty cycle
of 50% ?

It would also make it easier to get and set the frequency
when the duty cycle is assumed to be 50%.

Also, I'm not sure that a resolution of 1ms really is
appropriate, in case you encounter hardware with better
resolution. With ms, at high blink rates (>=100 Hz),
you're bound to 500,333,250,200,166,142,125,111,100 Hz,
which does not give you much control over the duty cycle
for devices with a high frequency.

Maybe you should express the on- and off- times in microseconds ?

Just my two cents anyway since I'm not directly concerned
by such devices.

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-02-18 09:11    [from the cache]
©2003-2008