* [PATCH] input: extend EV_LED @ 2007-02-11 10:02 Németh Márton 2007-02-12 18:31 ` Dmitry Torokhov 0 siblings, 1 reply; 17+ messages in thread From: Németh Márton @ 2007-02-11 10:02 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, linux-kernel 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 <nm127@freemail.hu> --- 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); ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-11 10:02 [PATCH] input: extend EV_LED Németh Márton @ 2007-02-12 18:31 ` Dmitry Torokhov 2007-02-14 19:06 ` Németh Márton 0 siblings, 1 reply; 17+ messages in thread From: Dmitry Torokhov @ 2007-02-12 18:31 UTC (permalink / raw) To: Németh Márton; +Cc: linux-input, linux-kernel On 2/11/07, Németh Márton <nm127@freemail.hu> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-12 18:31 ` Dmitry Torokhov @ 2007-02-14 19:06 ` Németh Márton 2007-02-14 19:49 ` Dmitry Torokhov 0 siblings, 1 reply; 17+ messages in thread From: Németh Márton @ 2007-02-14 19:06 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, linux-kernel Dmitry Torokhov <dmitry.torokhov@gmail.com> írta: > On 2/11/07, Németh Márton <nm127@freemail.hu> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-14 19:06 ` Németh Márton @ 2007-02-14 19:49 ` Dmitry Torokhov 2007-02-14 23:51 ` Németh Márton 2007-02-15 17:40 ` Pavel Machek 0 siblings, 2 replies; 17+ messages in thread From: Dmitry Torokhov @ 2007-02-14 19:49 UTC (permalink / raw) To: Németh Márton; +Cc: linux-input, linux-kernel On 2/14/07, Németh Márton <nm127@freemail.hu> wrote: > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> írta: > > > On 2/11/07, Németh Márton <nm127@freemail.hu> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-14 19:49 ` Dmitry Torokhov @ 2007-02-14 23:51 ` Németh Márton 2007-02-15 17:40 ` Pavel Machek 1 sibling, 0 replies; 17+ messages in thread From: Németh Márton @ 2007-02-14 23:51 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, linux-kernel Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On 2/14/07, Németh Márton <nm127@freemail.hu> wrote: > > > > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> írta: > > > > > On 2/11/07, Németh Márton <nm127@freemail.hu> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-14 19:49 ` Dmitry Torokhov 2007-02-14 23:51 ` Németh Márton @ 2007-02-15 17:40 ` Pavel Machek 2007-02-15 22:47 ` Németh Márton 1 sibling, 1 reply; 17+ messages in thread From: Pavel Machek @ 2007-02-15 17:40 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Németh Márton, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 17:40 ` Pavel Machek @ 2007-02-15 22:47 ` Németh Márton 2007-02-15 23:09 ` Richard Purdie 2007-02-16 14:04 ` Pavel Machek 0 siblings, 2 replies; 17+ messages in thread From: Németh Márton @ 2007-02-15 22:47 UTC (permalink / raw) To: Pavel Machek; +Cc: Dmitry Torokhov, Richard Purdie, linux-input, linux-kernel Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 22:47 ` Németh Márton @ 2007-02-15 23:09 ` Richard Purdie 2007-02-15 23:24 ` Pavel Machek ` (2 more replies) 2007-02-16 14:04 ` Pavel Machek 1 sibling, 3 replies; 17+ messages in thread From: Richard Purdie @ 2007-02-15 23:09 UTC (permalink / raw) To: Németh Márton Cc: Pavel Machek, Dmitry Torokhov, linux-input, linux-kernel On Thu, 2007-02-15 at 23:47 +0100, Németh Márton wrote: > Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 23:09 ` Richard Purdie @ 2007-02-15 23:24 ` Pavel Machek 2007-02-15 23:36 ` Richard Purdie 2007-02-16 3:12 ` Henrique de Moraes Holschuh 2007-02-18 7:45 ` Németh Márton 2 siblings, 1 reply; 17+ messages in thread From: Pavel Machek @ 2007-02-15 23:24 UTC (permalink / raw) To: Richard Purdie Cc: Németh Márton, Dmitry Torokhov, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 23:24 ` Pavel Machek @ 2007-02-15 23:36 ` Richard Purdie 0 siblings, 0 replies; 17+ messages in thread From: Richard Purdie @ 2007-02-15 23:36 UTC (permalink / raw) To: Pavel Machek Cc: Németh Márton, Dmitry Torokhov, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 23:09 ` Richard Purdie 2007-02-15 23:24 ` Pavel Machek @ 2007-02-16 3:12 ` Henrique de Moraes Holschuh 2007-02-18 11:05 ` Richard Purdie 2007-02-18 7:45 ` Németh Márton 2 siblings, 1 reply; 17+ messages in thread From: Henrique de Moraes Holschuh @ 2007-02-16 3:12 UTC (permalink / raw) To: linux-kernel; +Cc: Richard Purdie 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-16 3:12 ` Henrique de Moraes Holschuh @ 2007-02-18 11:05 ` Richard Purdie 2007-02-18 14:42 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 17+ messages in thread From: Richard Purdie @ 2007-02-18 11:05 UTC (permalink / raw) To: Henrique de Moraes Holschuh; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-18 11:05 ` Richard Purdie @ 2007-02-18 14:42 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 17+ messages in thread From: Henrique de Moraes Holschuh @ 2007-02-18 14:42 UTC (permalink / raw) To: Richard Purdie; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 23:09 ` Richard Purdie 2007-02-15 23:24 ` Pavel Machek 2007-02-16 3:12 ` Henrique de Moraes Holschuh @ 2007-02-18 7:45 ` Németh Márton 2007-02-18 8:07 ` Willy Tarreau 2007-02-18 11:12 ` Richard Purdie 2 siblings, 2 replies; 17+ messages in thread From: Németh Márton @ 2007-02-18 7:45 UTC (permalink / raw) To: Richard Purdie; +Cc: Pavel Machek, Dmitry Torokhov, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-18 7:45 ` Németh Márton @ 2007-02-18 8:07 ` Willy Tarreau 2007-02-18 11:12 ` Richard Purdie 1 sibling, 0 replies; 17+ messages in thread From: Willy Tarreau @ 2007-02-18 8:07 UTC (permalink / raw) To: Németh Márton Cc: Richard Purdie, Pavel Machek, Dmitry Torokhov, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-18 7:45 ` Németh Márton 2007-02-18 8:07 ` Willy Tarreau @ 2007-02-18 11:12 ` Richard Purdie 1 sibling, 0 replies; 17+ messages in thread From: Richard Purdie @ 2007-02-18 11:12 UTC (permalink / raw) To: Németh Márton Cc: Pavel Machek, Dmitry Torokhov, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] input: extend EV_LED 2007-02-15 22:47 ` Németh Márton 2007-02-15 23:09 ` Richard Purdie @ 2007-02-16 14:04 ` Pavel Machek 1 sibling, 0 replies; 17+ messages in thread From: Pavel Machek @ 2007-02-16 14:04 UTC (permalink / raw) To: Németh Márton Cc: Dmitry Torokhov, Richard Purdie, linux-input, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2007-02-18 14:42 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-11 10:02 [PATCH] input: extend EV_LED Németh Márton 2007-02-12 18:31 ` Dmitry Torokhov 2007-02-14 19:06 ` Németh Márton 2007-02-14 19:49 ` Dmitry Torokhov 2007-02-14 23:51 ` Németh Márton 2007-02-15 17:40 ` Pavel Machek 2007-02-15 22:47 ` Németh Márton 2007-02-15 23:09 ` Richard Purdie 2007-02-15 23:24 ` Pavel Machek 2007-02-15 23:36 ` Richard Purdie 2007-02-16 3:12 ` Henrique de Moraes Holschuh 2007-02-18 11:05 ` Richard Purdie 2007-02-18 14:42 ` Henrique de Moraes Holschuh 2007-02-18 7:45 ` Németh Márton 2007-02-18 8:07 ` Willy Tarreau 2007-02-18 11:12 ` Richard Purdie 2007-02-16 14:04 ` Pavel Machek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).