Messages in this thread |  | | Date | Sun, 18 Feb 2007 09:07:15 +0100 | From | Willy Tarreau <> | Subject | Re: [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/
|  |