Re: [PATCH] input: extend EV_LED

[Willy Tarreau]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/