Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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
Re: [PATCH] input: extend EV_LED
On Sun, Feb 18, 2007 at 08:45:00AM +0100, Németh Márton wrote: > > On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote: > > On Thu, 15 Feb 2007, Richard Purdie wrote: > > > This has been discussed in several places several times. > The problem > > > with hardware accelerated flashing is that you're are > often limited to > > > certain constraints (this case being no exception) and > indicating what > > > these are to userspace in a generic fashion is difficult. > > > > The hability to blinking at one rate is *very* common on > laptops. Blinking > > at a few discrete rates is also common enough. They > should be supported in > > a generic way. > > [...] > > Here's a suggestion for a simple, non-overengineered > interface: a "blink" > > attribute (on/off) for leds which can hardware-blink. > Only one blink > > frequency is common enough that this attribute by itself > is very useful > > (e.g. it is all a ThinkPad and most WiFi/network card leds > need). > > > > For hardware-blink leds with various frequencies, there is > the typical way > > to provide such things: give us a RO > blink_available_frequencies attribute > > which says which discrete frequencies are allowed (space > separated), and a > > RW blink_frequency attribute to set the frequency. If > instead of > > blink_available_frequencies, the driver provides RO > blink_frequency_min and > > _max attributes, then it means it can blink on that range > of freqs. > > > > That is simple enough to implement and use, and generic > enough. You just > > need to set in stone if you want the freq in Hz, or a > submultiple. You can > > even implement an optional "blink" software emulation that > drivers can hook > > into for systems where the driver *knows* that led access > is fast, but there > > is no hardware blinking emulation. > > > > A blinking led is basically a PWM (Pulse Width Modulation) > signal. A PWM signal has three different attribute. The > first one is the amplitude, this attribute is already > provided by the led subsystem as "brightness". There are two > more attributes, which are the frequency [Hz] and the duty > cycle [%], or the on-time [ms] and off-time [ms]. > > The frequency [Hz] and duty cycle [%] parameters has the > problem, that if we are limited to integers, it is not > possible to express slower blinks than 1Hz. We could also > use [mHz] (milli-Hertz), but it is not very common unit. > > The on-time [ms] and off-time [ms] seems to be easier to > handle (and this is also easier to simulate from software if > ever needed). An RO attribute could be introduced: > 'pwm_available', which can contain parameter pairs separated > by space, and the new parameter pair is in new line. An RW > attribute 'pwm' could accept a parameter pair separated by > space. > > A range could be also given in 'pwm_available', like this: > '500-1000 500-1000'. This has the limitation that if there > is a hardware which can blink a LED in differet freqencies, > but only with fixed 50% duty cycle, the on-time off-time > pair cannot express this range easily. > > My real-world example would be my Clevo D4J (D410J) > notebook's mail led. It has three known state: off, PWM at > 1Hz (50%), PWM at 0.5Hz (50%). In case the on-time [ms] > off-time [ms] parameter pairs are used: > > $ cat pwm_available > 500 500 > 1000 1000 > > What is your opinion? Maybe you should consider that if there's only one parameter, it implies both on- and off- times, leading to a duty cycle of 50% ? It would also make it easier to get and set the frequency when the duty cycle is assumed to be 50%. Also, I'm not sure that a resolution of 1ms really is appropriate, in case you encounter hardware with better resolution. With ms, at high blink rates (>=100 Hz), you're bound to 500,333,250,200,166,142,125,111,100 Hz, which does not give you much control over the duty cycle for devices with a high frequency. Maybe you should express the on- and off- times in microseconds ? Just my two cents anyway since I'm not directly concerned by such devices. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
On Sun, Feb 18, 2007 at 08:45:00AM +0100, Németh Márton wrote: On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote: On Thu, 15 Feb 2007, Richard Purdie wrote: This has been discussed in several places several times. The problem with hardware accelerated flashing is that you're are often limited to certain constraints (this case being no exception) and indicating what these are to userspace in a generic fashion is difficult. The hability to blinking at one rate is *very* common on laptops. Blinking at a few discrete rates is also common enough. They should be supported in a generic way. [...] Here's a suggestion for a simple, non-overengineered interface: a blink attribute (on/off) for leds which can hardware-blink. Only one blink frequency is common enough that this attribute by itself is very useful (e.g. it is all a ThinkPad and most WiFi/network card leds need). For hardware-blink leds with various frequencies, there is the typical way to provide such things: give us a RO blink_available_frequencies attribute which says which discrete frequencies are allowed (space separated), and a RW blink_frequency attribute to set the frequency. If instead of blink_available_frequencies, the driver provides RO blink_frequency_min and _max attributes, then it means it can blink on that range of freqs. That is simple enough to implement and use, and generic enough. You just need to set in stone if you want the freq in Hz, or a submultiple. You can even implement an optional blink software emulation that drivers can hook into for systems where the driver *knows* that led access is fast, but there is no hardware blinking emulation. A blinking led is basically a PWM (Pulse Width Modulation) signal. A PWM signal has three different attribute. The first one is the amplitude, this attribute is already provided by the led subsystem as brightness. There are two more attributes, which are the frequency [Hz] and the duty cycle [%], or the on-time [ms] and off-time [ms]. The frequency [Hz] and duty cycle [%] parameters has the problem, that if we are limited to integers, it is not possible to express slower blinks than 1Hz. We could also use [mHz] (milli-Hertz), but it is not very common unit. The on-time [ms] and off-time [ms] seems to be easier to handle (and this is also easier to simulate from software if ever needed). An RO attribute could be introduced: 'pwm_available', which can contain parameter pairs separated by space, and the new parameter pair is in new line. An RW attribute 'pwm' could accept a parameter pair separated by space. A range could be also given in 'pwm_available', like this: '500-1000 500-1000'. This has the limitation that if there is a hardware which can blink a LED in differet freqencies, but only with fixed 50% duty cycle, the on-time off-time pair cannot express this range easily. My real-world example would be my Clevo D4J (D410J) notebook's mail led. It has three known state: off, PWM at 1Hz (50%), PWM at 0.5Hz (50%). In case the on-time [ms] off-time [ms] parameter pairs are used: $ cat pwm_available 500 500 1000 1000 What is your opinion? Maybe you should consider that if there's only one parameter, it implies both on- and off- times, leading to a duty cycle of 50% ? It would also make it easier to get and set the frequency when the duty cycle is assumed to be 50%. Also, I'm not sure that a resolution of 1ms really is appropriate, in case you encounter hardware with better resolution. With ms, at high blink rates (=100 Hz), you're bound to 500,333,250,200,166,142,125,111,100 Hz, which does not give you much control over the duty cycle for devices with a high frequency. Maybe you should express the on- and off- times in microseconds ? Just my two cents anyway since I'm not directly concerned by such devices. Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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=frekszkar3435 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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=frekszkar3435 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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=397affiliate=frekszkar3435 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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=397affiliate=frekszkar3435 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: extend EV_LED
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
Re: [PATCH] input: extend EV_LED
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
[PATCH] 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. 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.0 +0100 +++ linux/drivers/input/input.c 2007-02-10 15:20:28.0 +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); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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. 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.0 +0100 +++ linux/drivers/input/input.c 2007-02-10 15:20:28.0 +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); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
