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.
Signed-off-by: M?rton N?meth <[email protected]>
---
diff -uprN linux-2.6.20.orig/drivers/input/input.c
linux/drivers/input/input.c
--- linux-2.6.20.orig/drivers/input/input.c 2007-02-04
19:44:54.000000000 +0100
+++ linux/drivers/input/input.c 2007-02-10 15:20:28.000000000 +0100
@@ -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);
On 2/11/07, N?meth M?rton <[email protected]> wrote:
>
> 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.
>
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).
--
Dmitry
Dmitry Torokhov <[email protected]> ?rta:
> On 2/11/07, N?meth M?rton <[email protected]> wrote:
> >
> > 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.
> >
>
> 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).
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
On 2/14/07, N?meth M?rton <[email protected]> wrote:
>
>
> Dmitry Torokhov <[email protected]> ?rta:
>
> > On 2/11/07, N?meth M?rton <[email protected]> wrote:
> > >
> > > 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.
> > >
> >
> > 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).
>
> 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?
>
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.
--
Dmitry
Dmitry Torokhov <[email protected]> wrote:
> On 2/14/07, N?meth M?rton <[email protected]> wrote:
> >
> >
> > Dmitry Torokhov <[email protected]> ?rta:
> >
> > > On 2/11/07, N?meth M?rton <[email protected]> wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > 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).
> >
> > 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?
> >
>
> 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.
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
On Thu, 2007-02-15 at 23:47 +0100, N?meth M?rton wrote:
> Pavel Machek <[email protected]> wrote:
> > > >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.
The led framework is generic. If you can write a function to turn it
on/off you can drive it with the LED framework.
> > 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.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?
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!
> > > > >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.
>
> 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?
> > > 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.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?
>
> 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.
I do not think we want to permit this led to run in "not accelerated"
mode. I believe i8042 accesses are pretty expensive.
> Nether patch exists yet.
Yep, interested party should create one of them :-). (And I'd prefer
the first one, due to i8042 slowness).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> wrote:
> Hi!
>
> > >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 :-).
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
On Fri, 2007-02-16 at 00:24 +0100, Pavel Machek wrote:
> > 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.
> > 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.
>
> 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...
> > 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
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.
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.
> 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)?
> 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.
--
"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
Hi!
> > > >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 :-).
>
> Hi,
>
> what do you mean about two leds? The first one would be
> off/0.5Hz and the other off/1Hz?
Somethinglike that.
> 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?
Seems so.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> >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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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?
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
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
On Fri, 2007-02-16 at 01:12 -0200, 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.
I just said that finding a way to do it generically is difficult, not
that we shouldn't do it.
> 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.
> 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...
> 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.
This is quite complex and whilst we could certainly have a trigger that
did this, we already have a variable frequency trigger. See below.
> 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.
> > 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)?
>
> > 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
On Sun, 2007-02-18 at 08:45 +0100, N?meth M?rton wrote:
> 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.
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
On Sun, 18 Feb 2007, Richard Purdie wrote:
> 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.
> 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).
> 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.
> 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.
> 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.
--
"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