Re: [PATCH] input: extend EV_LED
- From: Willy Tarreau <w@xxxxxx>
- Date: Sun, 18 Feb 2007 09:07:15 +0100
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:The problem
This has been discussed in several places several times.
often limited towith hardware accelerated flashing is that you're are
indicating whatcertain constraints (this case being no exception) and
laptops. Blinkingthese are to userspace in a generic fashion is difficult.
The hability to blinking at one rate is *very* common on
at a few discrete rates is also common enough. Theyshould be supported in
a generic way.interface: a "blink"
[...]
Here's a suggestion for a simple, non-overengineered
attribute (on/off) for leds which can hardware-blink.Only one blink
frequency is common enough that this attribute by itselfis very useful
(e.g. it is all a ThinkPad and most WiFi/network card ledsneed).
the typical way
For hardware-blink leds with various frequencies, there is
to provide such things: give us a ROblink_available_frequencies attribute
which says which discrete frequencies are allowed (spaceseparated), and a
RW blink_frequency attribute to set the frequency. Ifinstead of
blink_available_frequencies, the driver provides ROblink_frequency_min and
_max attributes, then it means it can blink on that rangeof freqs.
enough. You just
That is simple enough to implement and use, and generic
need to set in stone if you want the freq in Hz, or asubmultiple. You can
even implement an optional "blink" software emulation thatdrivers can hook
into for systems where the driver *knows* that led accessis 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/
- References:
- Re: [PATCH] input: extend EV_LED
- From: Richard Purdie
- Re: [PATCH] input: extend EV_LED
- From: Németh Márton
- Re: [PATCH] input: extend EV_LED
- Prev by Date: Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
- Next by Date: Re: [PATCH] override build timestamp
- Previous by thread: Re: [PATCH] input: extend EV_LED
- Next by thread: Re: [PATCH] input: extend EV_LED
- Index(es):
Relevant Pages
|
