input: extend EV_LED
Subsystems (2)
PATCH 1/1 input: extend EV_LED
Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND.
---
drivers/input/input.c +3 -2
@@ -141,10 +141,11 @@ void input_event(struct input_dev *dev,case EV_LED : -if (code >LED_MAX || !test_bit (code, dev->ledbit) || !!test_bit (code, dev->led) == value) +if (code >LED_MAX || !test_bit (code, dev->ledbit))return ; -change_bit (code, dev->led); +if (!!test_bit (code, dev->led) != !!value) +change_bit (code, dev->led);if (dev->event) dev->event (dev, type, code, value);
Dmitry Torokhov
maintainerQuoted 6 lines · Németh Márton
Extend
EV_LEDhandling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code atEV_SND.
Hi,
I am not sure we would need this, could you explain what are you trying to use input leds for?
Generally speaking leds within input subsystem are supposed to be very simple on/off objects, mostly for reporting state of input devices (keyboards), I am not even sure that LED_MAIL and LED_CHARGING make much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (drivers/leds).
Signature · 1 line
Dmitry
Dmitry Torokhov <[email protected]> írta:
Quoted 11 lines · Németh Márton
Quoted 6 lines
Extend
EV_LEDhandling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code atEV_SND.Hi,
I am not sure we would need this, could you explain what
are you
Quoted 3 lines
trying to use input leds for?
Generally speaking leds within input subsystem are
supposed to be very
Quoted 1 line
simple on/off objects, mostly for reporting state of input
devices
Quoted 1 line
(keyboards), I am not even sure that
LED_MAILand
LED_CHARGING make
Quoted 3 lines
much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (
drivers/leds).
The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz).
The mail LED can be programmed through the ports 0x60 and 0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlock i8042_lock held, which is defined as static in linux/drivers/input/serio/i8042.c .
What I miss currently from the input subsystem is that the EV_LED can only handle on/off state.
I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem.
What do you think and recommend?
NMarci
P.S.: my project home page is located at
http://clevo-mailled.sourceforge.net/
______________________________________________________________________
Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! Több mint 700 féle könyv 30% kedvezménnyel!
http://www.bookline.hu/control/news?newsid=397&affiliate=frekszkar3435
Dmitry Torokhov
maintainerQuoted 40 lines · Németh Márton
Dmitry Torokhov <[email protected]> írta:
Quoted 11 lines · Németh Márton
Quoted 6 lines
Extend
EV_LEDhandling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code atEV_SND.Hi,
I am not sure we would need this, could you explain what
are you
Quoted 3 lines
trying to use input leds for?
Generally speaking leds within input subsystem are
supposed to be very
Quoted 1 line
simple on/off objects, mostly for reporting state of input
devices
Quoted 1 line
(keyboards), I am not even sure that
LED_MAILand
LED_CHARGINGmakeQuoted 3 lines
much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (
drivers/leds).The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz).
The mail LED can be programmed through the ports
0x60and0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlocki8042_lockheld, which is defined as static inlinux/drivers/input/serio/i8042.c.
Quoted 9 lines
What I miss currently from the input subsystem is that the
EV_LEDcan only handle on/off state.I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem.
What do you think and recommend?
I think you need to use leds framework for what you are trying to do. I could export i8042_command() so you could access keyboard controller from your driver.
Signature · 1 line
Dmitry
Quoted 19 lines · Dmitry Torokhov
Quoted 18 lines · Németh Márton
Dmitry Torokhov <[email protected]> írta:
Quoted 11 lines · Németh Márton
Quoted 6 lines
Extend
EV_LEDhandling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code atEV_SND.Hi,
I am not sure we would need this, could you explain what
are you
Quoted 2 lines
trying to use input leds for?
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Generally speaking leds within input subsystem are
supposed to be very
Quoted 1 line
simple on/off objects, mostly for reporting state of input
devices
Quoted 1 line
(keyboards), I am not even sure that
LED_MAILand
LED_CHARGINGmakeQuoted 1 line
much sense here. For more compex
objects(blinking/different
Quoted 1 line
Quoted 1 line
Quoted 1 line
colors/different brightness) we have a separate LED
subsystem
Quoted 17 lines
Quoted 17 lines
Quoted 1 line
(
drivers/leds).The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz).
The mail LED can be programmed through the ports
0x60and0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlocki8042_lockheld, which is defined as static inlinux/drivers/input/serio/i8042.c.What I miss currently from the input subsystem is that the
EV_LEDcan only handle on/off state.
Quoted 8 lines
Quoted 6 lines
I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem.
What do you think and recommend?
I think you need to use leds framework for what you are
trying to do.
Quoted 1 line
I could export
i8042_command()so you could access
keyboard controller
Quoted 1 line
from your driver.
I think exporting the i8042_command() would solve my problem, so I could call:
retval = i8042_command(NULL, 0x0083);
retval = i8042_command(NULL, 0x0084);
retval = i8042_command(NULL, 0x008A);
as needed.
Which header file should the i8042_command() defined in?
NMarci
______________________________________________________________________
Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! Több mint 700 féle könyv 30% kedvezménnyel!
http://www.bookline.hu/control/news?newsid=397&affiliate=frekszkar3435
Hi!
Quoted 10 lines
Quoted 7 lines
I do not know the LED subsystem in detail, but I do not know
any possibility to access the i8042 from different subsystem
than the input subsystem.What do you think and recommend?
I think you need to use leds framework for what you are trying to do.
I'm actually not sure if led framework can do that. It was designed for leds on gpios, and handles blinking itself.
But he could export two leds :-).
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 8 lines · Pavel Machek
Hi!
Quoted 6 lines
Quoted 6 lines
I do not know the LED subsystem in detail, but I do not know
any possibility to access the i8042 from different subsystem
than the input subsystem.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
What do you think and recommend?
I think you need to use leds framework for what you are trying to do.
I'm actually not sure if led framework can do that. It was
designed
Quoted 3 lines
for leds on gpios, and handles blinking itself.
But he could export two leds :-).
Hi,
what do you mean about two leds? The first one would be off/0.5Hz and the other off/1Hz?
I read in linux/Documentation/led-class.txt the following:
| Some leds can be programmed to flash in hardware. As this isn't a generic
| LED device property, this should be exported as a device specific sysfs
| attribute rather than part of the class if this functionality is required.
Does it mean that neither the input subsystem nor the led subsystem is designed for hardware acelerated blinking leds? Is there any usual way what attribute a hw accelerated blinking LED_MAIL should export?
NMarci
______________________________________________________________________________
10.000 Ft ajándék fotókidolgozás minden Panasonic digitális fényképezőgéphez! FotoMarket Online Fotóáruház
http://ad.adverticum.net/b/cl,1,6022,99786,162268/click.prm
Quoted 5 lines · Németh Márton
Quoted 4 lines · Pavel Machek
Quoted 4 lines
Quoted 4 lines
I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem.
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
What do you think and recommend?
I think you need to use leds framework for what you are trying to do.
I'm actually not sure if led framework can do that. It was designed for leds on gpios, and handles blinking itself.
The led framework is generic. If you can write a function to turn it on/off you can drive it with the LED framework.
Quoted 14 lines
Quoted 1 line
But he could export two leds :-).
what do you mean about two leds? The first one would be off/0.5Hz and the other off/1Hz?
I read in
linux/Documentation/led-class.txtthe following:| Some leds can be programmed to flash in hardware. As this isn't a generic
| LED device property, this should be exported as a device specific sysfs
| attribute rather than part of the class if this functionality is required.
Quoted 4 lines
Does it mean that neither the input subsystem nor the led subsystem is designed for hardware acelerated blinking leds? Is there any usual way what attribute a hw accelerated blinking
LED_MAILshould export?
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.
One way I've come up with is adds capability to the class to have LED specific triggers and you can then expose these hardware capabilities as an extra trigger specific to the LED.
Another proposal more specific to this use case was to have some information behind the scenes which the software timer based trigger could use to turn on the "hardware acceleration" if present and capable of the requested mode. This might just need a function pointer in the core so could be quite neat.
Nether patch exists yet.
Cheers,
Richard
Hi!
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem.
What do you think and recommend?
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
I think you need to use leds framework for what you are trying to do.
I'm actually not sure if led framework can do that. It was designed for leds on gpios, and handles blinking itself.
The led framework is generic. If you can write a function to turn it on/off you can drive it with the LED framework.
Even if that function is slow and sleeps?
Quoted 28 lines
Quoted 14 lines
Quoted 1 line
But he could export two leds :-).
what do you mean about two leds? The first one would be off/0.5Hz and the other off/1Hz?
I read in
linux/Documentation/led-class.txtthe following:| Some leds can be programmed to flash in hardware. As this isn't a generic
| LED device property, this should be exported as a device specific sysfs
| attribute rather than part of the class if this functionality is required.Quoted 4 lines
Does it mean that neither the input subsystem nor the led subsystem is designed for hardware acelerated blinking leds? Is there any usual way what attribute a hw accelerated blinking
LED_MAILshould export?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.
One way I've come up with is adds capability to the class to have LED specific triggers and you can then expose these hardware capabilities as an extra trigger specific to the LED.
Quoted 5 lines
Another proposal more specific to this use case was to have some information behind the scenes which the software timer based trigger could use to turn on the "hardware acceleration" if present and capable of the requested mode. This might just need a function pointer in the core so could be quite neat.
I do not think we want to permit this led to run in "not accelerated" mode. I believe i8042 accesses are pretty expensive.
Quoted 1 line
Nether patch exists yet.
Yep, interested party should create one of them :-). (And I'd prefer the first one, due to i8042 slowness).
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 4 lines · Pavel Machek
Quoted 2 lines
The led framework is generic. If you can write a function to turn it on/off you can drive it with the LED framework.
Even if that function is slow and sleeps?
The LED class itself can call in interrupt context so you'd have to schedule a workqueue if you need to sleep.
Quoted 4 lines
Quoted 4 lines
One way I've come up with is adds capability to the class to have LED specific triggers and you can then expose these hardware capabilities as an extra trigger specific to the LED.
Quoted 8 lines
Quoted 5 lines
Another proposal more specific to this use case was to have some information behind the scenes which the software timer based trigger could use to turn on the "hardware acceleration" if present and capable of the requested mode. This might just need a function pointer in the core so could be quite neat.
I do not think we want to permit this led to run in "not accelerated" mode. I believe i8042 accesses are pretty expensive.
Which means they probably won't work well with the standard triggers. Not something we can do much about though...
Quoted 4 lines
Quoted 1 line
Nether patch exists yet.
Yep, interested party should create one of them :-). (And I'd prefer the first one, due to i8042 slowness).
Right, patches welcome :)
Cheers,
Richard
Quoted 4 lines · Richard Purdie
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.
I want to convert ibm-acpi to the led interface, but if it means I have to provide custom attributes on top of the led class, it sort of defeats most of the purpose of using the led class to begin with -- it will NOT be generic.
If I have to provide those attributes elsewhere in the sysfs tree other than somewhere in the led class, then it defeats the purpose of using the led class completely: I will just scrap the idea. I am not going to remove functionality. And I am not going to emulate in software something the hardware can do, especially when that means bothering the EC with a slow ACPI-subsystem-gated LPC bus IO port access for no good reason.
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.
Quoted 3 lines
One way I've come up with is adds capability to the class to have LED specific triggers and you can then expose these hardware capabilities as an extra trigger specific to the LED.
How would that look like? It doesn't sound too bad. Could you give us an example of what the tree would look like, and what the attributes would be (and do)?
Quoted 5 lines
Another proposal more specific to this use case was to have some information behind the scenes which the software timer based trigger could use to turn on the "hardware acceleration" if present and capable of the requested mode. This might just need a function pointer in the core so could be quite neat.
This looks like a severely overengineered way to deal with the problem at first glance.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 9 lines · Henrique de Moraes Holschuh
Quoted 4 lines · Richard Purdie
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.
I just said that finding a way to do it generically is difficult, not that we shouldn't do it.
Quoted 4 lines
I want to convert ibm-acpi to the led interface, but if it means I have to provide custom attributes on top of the led class, it sort of defeats most of the purpose of using the led class to begin with -- it will NOT be generic.
Even if half your functionality is exposed through the class, that half that is standardised rather than adhoc. Having said that, you shouldn't need any custom attributes though.
Quoted 11 lines
If I have to provide those attributes elsewhere in the sysfs tree other than somewhere in the led class, then it defeats the purpose of using the led class completely: I will just scrap the idea. I am not going to remove functionality. And I am not going to emulate in software something the hardware can do, especially when that means bothering the EC with a slow ACPI-subsystem-gated LPC bus IO port access for no good reason.
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).
Right, but blinking is not an LED attribute but more of an action for the LED so what we need is an LED blink trigger. Rather than the timer trigger which takes a variety of options, this blink trigger could just take an on/off value. In the absence of hardware capability, we can emulate it. I like the idea of a simple blink trigger...
Quoted 6 lines
For hardware-blink leds with various frequencies, there is the typical way to provide such things: give us a RO
blink_available_frequenciesattribute which says which discrete frequencies are allowed (space separated), and a RWblink_frequencyattribute to set the frequency. If instead ofblink_available_frequencies, the driver provides ROblink_frequency_minand_maxattributes, then it means it can blink on that range of freqs.
This is quite complex and whilst we could certainly have a trigger that did this, we already have a variable frequency trigger. See below.
Quoted 5 lines
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.
If a trigger/attribute appears for an LED, its behaviour needs to be the same for all LEDs.
Quoted 8 lines
Quoted 3 lines
One way I've come up with is adds capability to the class to have LED specific triggers and you can then expose these hardware capabilities as an extra trigger specific to the LED.
How would that look like? It doesn't sound too bad. Could you give us an example of what the tree would look like, and what the attributes would be (and do)?
Quoted 8 lines
Quoted 5 lines
Another proposal more specific to this use case was to have some information behind the scenes which the software timer based trigger could use to turn on the "hardware acceleration" if present and capable of the requested mode. This might just need a function pointer in the core so could be quite neat.
This looks like a severely overengineered way to deal with the problem at first glance.
Which means you haven't thought about it as its quite simple in software terms. The LED driver can optionally implement a couple of functions:
set_blink(enum frequency)set_blink_frequency(int delay_on, int delay_off)
These are not exported as an attribute directly and are just something triggers can use. Any trigger needing blinking behaviour calls one of these functions as appropriate and if implemented.
The enum reflects a spectrum of loosely defined frequencies, a bit like brightness maybe in a range 0-6. The idea is these are loose definitions and the driver will attempt a loose match, using any hardware blinking if available.
In the case of an LED with a full blown PWM capability (which can support near enough any frequency), it could just implement set_blink_frequency() and the LED core could provide a set_blink() function which translated into a call to set_blink_frequency() with some predefined frequency defaults. If it didn't support the parameters passed, it returns an error which the trigger would have to handle with a software default.
Yes, this is a slightly complicated solution but it solves 101 other scenarios other than just yours and allows hardware acceleration of things like the generic timer trigger as well as hardware acceleration of any trigger which wants a flashing LED instead of an LED thats just turned on.
Regards,
Richard
Quoted 2 lines · Richard Purdie
I just said that finding a way to do it generically is difficult, not that we shouldn't do it.
Very well, let's do it, then.
Quoted 3 lines
Even if half your functionality is exposed through the class, that half that is standardised rather than adhoc. Having said that, you shouldn't need any custom attributes though.
Yes, that's my point. Blinking is too common, it needs to be generic (and I don't care if it is done through triggers, as long as it is generic *and* hardware-implementation-friendly, I will use it).
Quoted 5 lines
Right, but blinking is not an LED attribute but more of an action for the LED so what we need is an LED blink trigger. Rather than the timer trigger which takes a variety of options, this blink trigger could just take an on/off value. In the absence of hardware capability, we can emulate it. I like the idea of a simple blink trigger...
If you have a 2.6.20 backport of the new LED class, I could work on it when I finish the ibm-acpi conversion to sysfs, which should take about one more week.
Quoted 2 lines
If a trigger/attribute appears for an LED, its behaviour needs to be the same for all LEDs.
Agreed.
BTW: I need to have two leds that are the same device, different colors. The code already handles this just fine (it is NOT a multicolor led), I'd like to know how should I name the parameter?
power:green and power:yellow?
That should be done in a standard way as well.
Quoted 4 lines
The enum reflects a spectrum of loosely defined frequencies, a bit like brightness maybe in a range 0-6. The idea is these are loose definitions and the driver will attempt a loose match, using any hardware blinking if available.
Add the following functionality, and I think I would be happy with the interface:
1. A way for the driver to say "led access is expensive, do not enable software blink emulation" (maybe you already have this...)
2. A way for userspace to either know which ranges are hardware-emulated, or to request that only hardware emulation be used.
I can live with just (1), but I think (2) would make the interface more complete. Keep in mind that whatever can be hardware-emulated is probably the default way to use that led, so it is an interesting data-point for userspace.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 2 lines · Henrique de Moraes Holschuh
Quoted 1 line · Richard Purdie
This has been discussed in several places several times.
The problem
Quoted 1 line
Quoted 1 line
with hardware accelerated flashing is that you're are
often limited to
Quoted 1 line
Quoted 1 line
certain constraints (this case being no exception) and
indicating what
Quoted 3 lines
Quoted 1 line
these are to userspace in a generic fashion is difficult.
The hability to blinking at one rate is *very* common on
laptops. Blinking
Quoted 1 line
at a few discrete rates is also common enough. They
should be supported in
Quoted 3 lines
a generic way.
[...]
Here's a suggestion for a simple, non-overengineered
interface: a "blink"
Quoted 1 line
attribute (on/off) for leds which can hardware-blink.
Only one blink
Quoted 1 line
frequency is common enough that this attribute by itself
is very useful
Quoted 1 line
(e.g. it is all a ThinkPad and most WiFi/network card leds
need).
Quoted 2 lines
For hardware-blink leds with various frequencies, there is
the typical way
Quoted 1 line
to provide such things: give us a RO
blink_available_frequencies attribute
Quoted 1 line
which says which discrete frequencies are allowed (space
separated), and a
Quoted 1 line
RW
blink_frequencyattribute to set the frequency. If
instead of
Quoted 1 line
blink_available_frequencies, the driver provides RO
blink_frequency_min and
Quoted 1 line
_maxattributes, then it means it can blink on that range
of freqs.
Quoted 2 lines
That is simple enough to implement and use, and generic
enough. You just
Quoted 1 line
need to set in stone if you want the freq in Hz, or a
submultiple. You can
Quoted 1 line
even implement an optional "blink" software emulation that
drivers can hook
Quoted 1 line
into for systems where the driver *knows* that led access
is fast, but there
Quoted 2 lines
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?
Is there more real-world hardware accelerated blinking LED parameter examples?
NMarci
__________________________________________________________________________
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!
http://ad.adverticum.net/b/cl,1,6022,131839,203066/click.prm
Quoted 81 lines · Németh Márton
Quoted 2 lines · Henrique de Moraes Holschuh
Quoted 1 line · Richard Purdie
This has been discussed in several places several times.
The problem
Quoted 1 line
Quoted 1 line
with hardware accelerated flashing is that you're are
often limited to
Quoted 1 line
Quoted 1 line
certain constraints (this case being no exception) and
indicating what
Quoted 3 lines
Quoted 1 line
these are to userspace in a generic fashion is difficult.
The hability to blinking at one rate is *very* common on
laptops. Blinking
Quoted 1 line
at a few discrete rates is also common enough. They
should be supported in
Quoted 3 lines
a generic way.
[...]
Here's a suggestion for a simple, non-overengineeredinterface: a "blink"
Quoted 1 line
attribute (on/off) for leds which can hardware-blink.
Only one blink
Quoted 1 line
frequency is common enough that this attribute by itself
is very useful
Quoted 1 line
(e.g. it is all a ThinkPad and most WiFi/network card leds
need).
Quoted 2 lines
For hardware-blink leds with various frequencies, there is
the typical way
Quoted 1 line
to provide such things: give us a RO
blink_available_frequenciesattributeQuoted 1 line
which says which discrete frequencies are allowed (space
separated), and a
Quoted 1 line
RW
blink_frequencyattribute to set the frequency. Ifinstead of
Quoted 1 line
blink_available_frequencies, the driver provides RO
blink_frequency_minandQuoted 1 line
_maxattributes, then it means it can blink on that rangeof freqs.
Quoted 2 lines
That is simple enough to implement and use, and generic
enough. You just
Quoted 1 line
need to set in stone if you want the freq in Hz, or a
submultiple. You can
Quoted 1 line
even implement an optional "blink" software emulation that
drivers can hook
Quoted 1 line
into for systems where the driver *knows* that led access
is fast, but there
Quoted 2 lines
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:
Quoted 5 lines
$ cat pwm_available 500 500 1000 1000What 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
Quoted 12 lines · Németh Márton
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.
Quoted 7 lines
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.
We already have a timer trigger which takes an on time and an off time for the reason you mention above (floating point would get ugly).
The problem is mainly about finding ways to enable hardware acceleration of the existing timer trigger (where possible) and maybe implementing a simpler blink trigger which could be hardware accelerated when the full blown timer trigger couldn't.
Regards,
Richard
Hi!
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I do not know the LED subsystem in detail, but I do not know
any possibility to access the i8042 from different subsystem
than the input subsystem.Quoted 6 lines
Quoted 4 lines
Quoted 1 line
What do you think and recommend?
I think you need to use leds framework for what you are trying to do.
I'm actually not sure if led framework can do that. It was
designed
Quoted 8 lines
Quoted 3 lines
for leds on gpios, and handles blinking itself.
But he could export two leds :-).
Hi,
what do you mean about two leds? The first one would be off/0.5Hz and the other off/1Hz?
Somethinglike that.
Quoted 11 lines
I read in
linux/Documentation/led-class.txtthe following:| Some leds can be programmed to flash in hardware. As this isn't a generic
| LED device property, this should be exported as a device specific sysfs
| attribute rather than part of the class if this functionality is required.Does it mean that neither the input subsystem nor the led subsystem is designed for hardware acelerated blinking leds?
Seems so.
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html