* 2.6: drivers/input/power.c is never built @ 2005-02-13 0:47 Adrian Bunk 2005-02-14 18:04 ` James Simmons 0 siblings, 1 reply; 46+ messages in thread From: Adrian Bunk @ 2005-02-13 0:47 UTC (permalink / raw) To: James Simmons; +Cc: vojtech, linux-input, linux-kernel In 2.6, drivers/input/power.c would only have been built if CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable this option. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-13 0:47 2.6: drivers/input/power.c is never built Adrian Bunk @ 2005-02-14 18:04 ` James Simmons 2005-02-14 19:34 ` Vojtech Pavlik 0 siblings, 1 reply; 46+ messages in thread From: James Simmons @ 2005-02-14 18:04 UTC (permalink / raw) To: Adrian Bunk Cc: Vojtech Pavlik, Linux Input Devices, Linux Kernel Mailing List > In 2.6, drivers/input/power.c would only have been built if > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable > this option. That was written a long time ago before the new power management went in. On PDA's there is a power button and suspend button. So this was a hook so that the input layer could detect the power/suspend button being presses and then power down or turn off the device. Now that the new power management is in what should we do? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-14 18:04 ` James Simmons @ 2005-02-14 19:34 ` Vojtech Pavlik 2005-02-18 12:22 ` Pavel Machek 0 siblings, 1 reply; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-14 19:34 UTC (permalink / raw) To: James Simmons; +Cc: Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Mon, Feb 14, 2005 at 06:04:03PM +0000, James Simmons wrote: > > > In 2.6, drivers/input/power.c would only have been built if > > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable > > this option. > > That was written a long time ago before the new power management went in. > On PDA's there is a power button and suspend button. So this was a hook > so that the input layer could detect the power/suspend button being > presses and then power down or turn off the device. Now that the new power > management is in what should we do? Change power.c to generate power events like ACPI does, most likely. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-14 19:34 ` Vojtech Pavlik @ 2005-02-18 12:22 ` Pavel Machek 2005-02-18 13:10 ` Richard Purdie 0 siblings, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 12:22 UTC (permalink / raw) To: Vojtech Pavlik Cc: James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > > In 2.6, drivers/input/power.c would only have been built if > > > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable > > > this option. > > > > That was written a long time ago before the new power management went in. > > On PDA's there is a power button and suspend button. So this was a hook > > so that the input layer could detect the power/suspend button being > > presses and then power down or turn off the device. Now that the new power > > management is in what should we do? > > Change power.c to generate power events like ACPI does, most likely. Actually I believe you want to fix ACPI to use inputs. You hardly want /proc/acpi/events on PDA, right? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 12:22 ` Pavel Machek @ 2005-02-18 13:10 ` Richard Purdie 2005-02-18 13:26 ` Pavel Machek 0 siblings, 1 reply; 46+ messages in thread From: Richard Purdie @ 2005-02-18 13:10 UTC (permalink / raw) To: Pavel Machek, Vojtech Pavlik, James Simmons, Adrian Bunk Cc: Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov > > > In 2.6, drivers/input/power.c would only have been built if > > > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable > > > this option. > > > > That was written a long time ago before the new power management went > > in. > > On PDA's there is a power button and suspend button. So this was a hook > > so that the input layer could detect the power/suspend button being > > presses and then power down or turn off the device. Now that the new > > power > > management is in what should we do? > > Change power.c to generate power events like ACPI does, most likely. There was some recent discussion of this on linux-input. It was basically agreed that the input system should pass the request on to ACPI and/or apm and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed to be slightly modified to work with arm apm, the final result being: http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch I can confirm this works well on arm with apm enabled. Regards, Richard ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 13:10 ` Richard Purdie @ 2005-02-18 13:26 ` Pavel Machek 2005-02-18 13:36 ` Oliver Neukum ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Pavel Machek @ 2005-02-18 13:26 UTC (permalink / raw) To: Richard Purdie Cc: Vojtech Pavlik, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov Hi! > >> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable > >> > this option. > >> > >> That was written a long time ago before the new power management went > >> in. > >> On PDA's there is a power button and suspend button. So this was a hook > >> so that the input layer could detect the power/suspend button being > >> presses and then power down or turn off the device. Now that the new > >> power > >> management is in what should we do? > > > >Change power.c to generate power events like ACPI does, most likely. > > > There was some recent discussion of this on linux-input. It was basically > agreed that the input system should pass the request on to ACPI and/or apm > and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed > to be slightly modified to work with arm apm, the final result being: > > http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch > > I can confirm this works well on arm with apm enabled. It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, and it will not work on i386/APM, anyway. I still believe right solution is to add input interface to ACPI. /proc/acpi/events needs to die, being replaced by input subsystem. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 13:26 ` Pavel Machek @ 2005-02-18 13:36 ` Oliver Neukum 2005-02-18 16:01 ` Pavel Machek 2005-02-18 14:02 ` Richard Purdie 2005-02-18 14:12 ` Dmitry Torokhov 2 siblings, 1 reply; 46+ messages in thread From: Oliver Neukum @ 2005-02-18 13:36 UTC (permalink / raw) To: Pavel Machek Cc: Richard Purdie, Vojtech Pavlik, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > and it will not work on i386/APM, anyway. I still believe right > solution is to add input interface to ACPI. /proc/acpi/events needs to > die, being replaced by input subsystem. But aren't there power events (battery low, etc) which are not input events? Regards Oliver ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 13:36 ` Oliver Neukum @ 2005-02-18 16:01 ` Pavel Machek 2005-02-18 17:00 ` Vojtech Pavlik 0 siblings, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 16:01 UTC (permalink / raw) To: Oliver Neukum Cc: Richard Purdie, Vojtech Pavlik, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov Hi! > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > and it will not work on i386/APM, anyway. I still believe right > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > die, being replaced by input subsystem. > > But aren't there power events (battery low, etc) which are not > input events? Yes, there are. They can probably stay... Or we can get "battery low" key. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 16:01 ` Pavel Machek @ 2005-02-18 17:00 ` Vojtech Pavlik 2005-02-18 17:05 ` Oliver Neukum 2005-02-18 18:19 ` Dmitry Torokhov 0 siblings, 2 replies; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-18 17:00 UTC (permalink / raw) To: Pavel Machek Cc: Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote: > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > > and it will not work on i386/APM, anyway. I still believe right > > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > > die, being replaced by input subsystem. > > > > But aren't there power events (battery low, etc) which are not > > input events? > > Yes, there are. They can probably stay... Or we can get "battery low" > key. We even have an event class for that, EV_PWR in the input subsystem. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 17:00 ` Vojtech Pavlik @ 2005-02-18 17:05 ` Oliver Neukum 2005-02-18 17:48 ` Vojtech Pavlik 2005-02-18 20:14 ` Pavel Machek 2005-02-18 18:19 ` Dmitry Torokhov 1 sibling, 2 replies; 46+ messages in thread From: Oliver Neukum @ 2005-02-18 17:05 UTC (permalink / raw) To: Vojtech Pavlik Cc: Pavel Machek, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov Am Freitag, 18. Februar 2005 18:00 schrieb Vojtech Pavlik: > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote: > > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > > > and it will not work on i386/APM, anyway. I still believe right > > > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > > > die, being replaced by input subsystem. > > > > > > But aren't there power events (battery low, etc) which are not > > > input events? > > > > Yes, there are. They can probably stay... Or we can get "battery low" > > key. > > We even have an event class for that, EV_PWR in the input subsystem. Over that route we'd arrive at a situation where power management without the input layer is impossible. Think about embedded stuff I wonder whether this is viable. Regards Oliver ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 17:05 ` Oliver Neukum @ 2005-02-18 17:48 ` Vojtech Pavlik 2005-02-18 21:32 ` James Simmons 2005-02-18 20:14 ` Pavel Machek 1 sibling, 1 reply; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-18 17:48 UTC (permalink / raw) To: Oliver Neukum Cc: Pavel Machek, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov On Fri, Feb 18, 2005 at 06:05:12PM +0100, Oliver Neukum wrote: > Am Freitag, 18. Februar 2005 18:00 schrieb Vojtech Pavlik: > > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote: > > > > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > > > > and it will not work on i386/APM, anyway. I still believe right > > > > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > > > > die, being replaced by input subsystem. > > > > > > > > But aren't there power events (battery low, etc) which are not > > > > input events? > > > > > > Yes, there are. They can probably stay... Or we can get "battery low" > > > key. > > > > We even have an event class for that, EV_PWR in the input subsystem. > > Over that route we'd arrive at a situation where power management > without the input layer is impossible. All you'd need is input.c. One file, approx 750 lines at the moment, a big chunk of that can be confugured out if you don't need procfs or hotplug. > Think about embedded stuff I wonder whether this is viable. On most embedded platforms you have some buttons or controls, so it's likely you'll use input anyway. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 17:48 ` Vojtech Pavlik @ 2005-02-18 21:32 ` James Simmons 0 siblings, 0 replies; 46+ messages in thread From: James Simmons @ 2005-02-18 21:32 UTC (permalink / raw) To: Vojtech Pavlik Cc: Oliver Neukum, Pavel Machek, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov > All you'd need is input.c. One file, approx 750 lines at the moment, a > big chunk of that can be confugured out if you don't need procfs or > hotplug. > > > Think about embedded stuff I wonder whether this is viable. > > On most embedded platforms you have some buttons or controls, so it's > likely you'll use input anyway. I have always used the input api on embedded devices. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 17:05 ` Oliver Neukum 2005-02-18 17:48 ` Vojtech Pavlik @ 2005-02-18 20:14 ` Pavel Machek 2005-02-18 20:39 ` Oliver Neukum 1 sibling, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 20:14 UTC (permalink / raw) To: Oliver Neukum Cc: Vojtech Pavlik, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov Hi! > > > Yes, there are. They can probably stay... Or we can get "battery low" > > > key. > > > > We even have an event class for that, EV_PWR in the input subsystem. > > Over that route we'd arrive at a situation where power management > without the input layer is impossible. Think about embedded stuff I wonder > whether this is viable. I'd say it is: you need some support to get it into userspace. And I'd certianly prefer input infrastructure over ACPI infrastructure... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 20:14 ` Pavel Machek @ 2005-02-18 20:39 ` Oliver Neukum 0 siblings, 0 replies; 46+ messages in thread From: Oliver Neukum @ 2005-02-18 20:39 UTC (permalink / raw) To: Pavel Machek Cc: Vojtech Pavlik, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov Am Freitag, 18. Februar 2005 21:14 schrieb Pavel Machek: > Hi! > > > > > Yes, there are. They can probably stay... Or we can get "battery low" > > > > key. > > > > > > We even have an event class for that, EV_PWR in the input subsystem. > > > > Over that route we'd arrive at a situation where power management > > without the input layer is impossible. Think about embedded stuff I wonder > > whether this is viable. > > I'd say it is: you need some support to get it into userspace. And I'd > certianly prefer input infrastructure over ACPI infrastructure... If it could replace ACPI (or some abstraction thereof), maybe. But power management needs communication in both ways (like setting warn levels and transfers complex things, like queries for battery power which cannot easily be abstracted as events) Regards Oliver ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 17:00 ` Vojtech Pavlik 2005-02-18 17:05 ` Oliver Neukum @ 2005-02-18 18:19 ` Dmitry Torokhov 2005-02-18 18:39 ` Vojtech Pavlik 1 sibling, 1 reply; 46+ messages in thread From: Dmitry Torokhov @ 2005-02-18 18:19 UTC (permalink / raw) To: Vojtech Pavlik Cc: Pavel Machek, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote: > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote: > > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > > > and it will not work on i386/APM, anyway. I still believe right > > > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > > > die, being replaced by input subsystem. > > > > > > But aren't there power events (battery low, etc) which are not > > > input events? > > > > Yes, there are. They can probably stay... Or we can get "battery low" > > key. > > We even have an event class for that, EV_PWR in the input subsystem. I really really think this is wrong. Power management should be possible without input layer. EV_PWR is fine for telling input devices to do something, like enter lower power mode and for sending _some_ requests to the PM system. But input layer shoudl not be used as a generic transport. I mean battery low, docking requests, etc has nothing to do with input. -- Dmitry ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 18:19 ` Dmitry Torokhov @ 2005-02-18 18:39 ` Vojtech Pavlik 2005-02-18 19:20 ` Dmitry Torokhov 0 siblings, 1 reply; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-18 18:39 UTC (permalink / raw) To: dtor_core Cc: Pavel Machek, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote: > On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote: > > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote: > > > > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > > > > and it will not work on i386/APM, anyway. I still believe right > > > > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > > > > die, being replaced by input subsystem. > > > > > > > > But aren't there power events (battery low, etc) which are not > > > > input events? > > > > > > Yes, there are. They can probably stay... Or we can get "battery low" > > > key. > > > > We even have an event class for that, EV_PWR in the input subsystem. > > I really really think this is wrong. Power management should be > possible without input layer. EV_PWR is fine for telling input devices > to do something, like enter lower power mode Definitely not for this. The request to go to low power mode should come from the other side - the bus the device lives on. > and for sending _some_ requests to the PM system. I don't think input devices themselves should be sending any requests to the PM system at all, they should just pass the events to the userspace and have that decide what to do with it. Maybe a simple event handler like power.c for transforming key events to power change requests for embedded systems makes sense, but normally many more variables need to be taken into account, and thus userspace needs to decide. > But input layer shoudl not be used as a generic transport. I mean > battery low, docking requests, etc has nothing to do with input. Well, plugging in a power cord is a physical user action much like closing the lid is, much like pressing the power button is, much like pressing a key is. I definitely wouldn't want to see input to be a generic trasport layer - it is not. But I wouldn't be opposed to pass some of the user induced events through it. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 18:39 ` Vojtech Pavlik @ 2005-02-18 19:20 ` Dmitry Torokhov 2005-02-18 20:05 ` Vojtech Pavlik 0 siblings, 1 reply; 46+ messages in thread From: Dmitry Torokhov @ 2005-02-18 19:20 UTC (permalink / raw) To: Vojtech Pavlik Cc: Pavel Machek, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, 18 Feb 2005 19:39:36 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote: > On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote: > > On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote: > > > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote: > > > > > > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > > > > > > and it will not work on i386/APM, anyway. I still believe right > > > > > > solution is to add input interface to ACPI. /proc/acpi/events needs to > > > > > > die, being replaced by input subsystem. > > > > > > > > > > But aren't there power events (battery low, etc) which are not > > > > > input events? > > > > > > > > Yes, there are. They can probably stay... Or we can get "battery low" > > > > key. > > > > > > We even have an event class for that, EV_PWR in the input subsystem. > > > > I really really think this is wrong. Power management should be > > possible without input layer. EV_PWR is fine for telling input devices > > to do something, like enter lower power mode > > Definitely not for this. The request to go to low power mode should come > from the other side - the bus the device lives on. Probably not. On the other hand input layer is kind of a hyper-transport allowing to send messages to several devices at one regardless of the bis they are reside on. > > > and for sending _some_ requests to the PM system. > > I don't think input devices themselves should be sending any requests to > the PM system at all, they should just pass the events to the userspace > and have that decide what to do with it. > > Maybe a simple event handler like power.c for transforming key events to > power change requests for embedded systems makes sense, but normally > many more variables need to be taken into account, and thus userspace > needs to decide. > I never said it should go staringt into the core of ACPI and performing some action. That hack to power.c that I did was effectively sending message to acpid giving userspace a chance to make decision and react to the request. > > But input layer shoudl not be used as a generic transport. I mean > > battery low, docking requests, etc has nothing to do with input. > > Well, plugging in a power cord is a physical user action much like > closing the lid is, much like pressing the power button is, much like > pressing a key is. What about power dying and my UPS switing on? I think it is out of input layer, we need PM/system state messaging layer. It can be based on acpi events and acpid or maybe kevents (but I don't like the idea of needing kobjects for that). Still power.c seems like the good place to hide all the ugliness and glue between that new (or old) layer and input layer. -- Dmitry ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 19:20 ` Dmitry Torokhov @ 2005-02-18 20:05 ` Vojtech Pavlik 2005-02-18 20:24 ` Pavel Machek 0 siblings, 1 reply; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-18 20:05 UTC (permalink / raw) To: dtor_core Cc: Pavel Machek, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, Feb 18, 2005 at 02:20:13PM -0500, Dmitry Torokhov wrote: > > > But input layer shoudl not be used as a generic transport. I mean > > > battery low, docking requests, etc has nothing to do with input. > > > > Well, plugging in a power cord is a physical user action much like > > closing the lid is, much like pressing the power button is, much like > > pressing a key is. > > What about power dying and my UPS switing on? I think it is out of > input layer, Yes, I was thinking about this, too. An UPS is pretty much the same thing to a desktop as a battery is to a notebook. And I also got to the conclusion that this is a bad idea. But now that you are talking about this, I think there is some merit to that way. UPSes are usually handled by userspace daemons, either through serial ports or via USB over hiddev (which is another driver that should be redone from scratch). So we may need a way to loop these events through the kernel to make them available to the power event handling software. uinput would be a rather straightforward solution here ... > we need PM/system state messaging layer. It can be based > on acpi events and acpid or maybe kevents (but I don't like the idea > of needing kobjects for that). ACPI is too platform specific. We really need some platform independent way to be able to have a simple software solution. > Still power.c seems like the good place to hide all the ugliness and > glue between that new (or old) layer and input layer. Yes, it's a reasonable way. But the other way around (passing most power related events through input) also is quite compelling. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 20:05 ` Vojtech Pavlik @ 2005-02-18 20:24 ` Pavel Machek 2005-02-18 20:40 ` Vojtech Pavlik 0 siblings, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 20:24 UTC (permalink / raw) To: Vojtech Pavlik Cc: dtor_core, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > > > But input layer shoudl not be used as a generic transport. I mean > > > > battery low, docking requests, etc has nothing to do with input. > > > > > > Well, plugging in a power cord is a physical user action much like > > > closing the lid is, much like pressing the power button is, much like > > > pressing a key is. > > > > What about power dying and my UPS switing on? I think it is out of > > input layer, > > Yes, I was thinking about this, too. An UPS is pretty much the same > thing to a desktop as a battery is to a notebook. And I also got to the > conclusion that this is a bad idea. Well, I'm not sure if input layer is suitable for batteries... Modern battery has quite a lot of parameters. It can tell you current voltage, current capacity (either mAh or mWh), design capacity, last capacity at full charge, current current, battery's estimate of run time (which may be better than system's estimate), ... But some batteries only know percentage of energy left, and some batteries only know current voltage (you can estimate %left from that). I'm not sure if input system can handle all that complexity... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 20:24 ` Pavel Machek @ 2005-02-18 20:40 ` Vojtech Pavlik 2005-02-18 20:59 ` Pavel Machek 2005-02-18 21:23 ` Oliver Neukum 0 siblings, 2 replies; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-18 20:40 UTC (permalink / raw) To: Pavel Machek Cc: dtor_core, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, Feb 18, 2005 at 09:24:43PM +0100, Pavel Machek wrote: > Hi! > > > > > > But input layer shoudl not be used as a generic transport. I mean > > > > > battery low, docking requests, etc has nothing to do with input. > > > > > > > > Well, plugging in a power cord is a physical user action much like > > > > closing the lid is, much like pressing the power button is, much like > > > > pressing a key is. > > > > > > What about power dying and my UPS switing on? I think it is out of > > > input layer, > > > > Yes, I was thinking about this, too. An UPS is pretty much the same > > thing to a desktop as a battery is to a notebook. And I also got to the > > conclusion that this is a bad idea. > > Well, I'm not sure if input layer is suitable for batteries... Modern > battery has quite a lot of parameters. It can tell you current > voltage, current capacity (either mAh or mWh), design capacity, last > capacity at full charge, current current, battery's estimate of run > time (which may be better than system's estimate), ... But some > batteries only know percentage of energy left, and some batteries only > know current voltage (you can estimate %left from that). I'm not sure > if input system can handle all that complexity... I wouldn't want to pass all the battery info (UPSes can be even more complex, able to switch on/off individual sockets, etc) through input, just the basic events: AC power on/off battery full/normal/low/critical/(fail) Then the other power-related events Lid open/closed Power button Sleep button I think that's all you need to trigger actions. You don't need the exact percentage of the battery, and you don't need the exact AC voltage at input. Nice graphics battery monitors in X can gather their information from the platform specific sources, since they'll need it all in the greatest detail. PS. full = not charging normal = OK state, charging if AC low = better shutdown if you don't want to stress the battery (namely LiIon batteries prefer not to be discharged too much) critical = last chance to shutdown cleanly fail = battery present, but doesn't work. A server, while booting should wait for battery going at least to 'low' before mounting system read/write, otherwise subsequent power failures might cause damage. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 20:40 ` Vojtech Pavlik @ 2005-02-18 20:59 ` Pavel Machek 2005-02-18 21:23 ` Oliver Neukum 1 sibling, 0 replies; 46+ messages in thread From: Pavel Machek @ 2005-02-18 20:59 UTC (permalink / raw) To: Vojtech Pavlik Cc: dtor_core, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > Well, I'm not sure if input layer is suitable for batteries... Modern > > battery has quite a lot of parameters. It can tell you current > > voltage, current capacity (either mAh or mWh), design capacity, last > > capacity at full charge, current current, battery's estimate of run > > time (which may be better than system's estimate), ... But some > > batteries only know percentage of energy left, and some batteries only > > know current voltage (you can estimate %left from that). I'm not sure > > if input system can handle all that complexity... > > I wouldn't want to pass all the battery info (UPSes can be even more > complex, able to switch on/off individual sockets, etc) through input, > just the basic events: > > AC power on/off > battery full/normal/low/critical/(fail) > > Then the other power-related events > > Lid open/closed > Power button > Sleep button > > I think that's all you need to trigger actions. You don't need the exact > percentage of the battery, and you don't need the exact AC voltage at > input. > > Nice graphics battery monitors in X can gather their information from > the platform specific sources, since they'll need it all in the greatest > detail. Makes sense. Other possibility is to have simple "battery status changed" event, but that would not be enough for simple UPSes... I guess battery full/normal/low/critical makes sense, perhaps I'd say that battery might repeat event if something "interesting" changed. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 20:40 ` Vojtech Pavlik 2005-02-18 20:59 ` Pavel Machek @ 2005-02-18 21:23 ` Oliver Neukum 2005-02-18 21:34 ` Pavel Machek 2005-02-18 21:38 ` Vojtech Pavlik 1 sibling, 2 replies; 46+ messages in thread From: Oliver Neukum @ 2005-02-18 21:23 UTC (permalink / raw) To: Vojtech Pavlik Cc: Pavel Machek, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Am Freitag, 18. Februar 2005 21:40 schrieb Vojtech Pavlik: > I wouldn't want to pass all the battery info (UPSes can be even more > complex, able to switch on/off individual sockets, etc) through input, > just the basic events: > > AC power on/off > battery full/normal/low/critical/(fail) > > Then the other power-related events > > Lid open/closed > Power button > Sleep button What is the benefit of splitting the flow of information so? > I think that's all you need to trigger actions. You don't need the exact > percentage of the battery, and you don't need the exact AC voltage at > input. That is very debateable. I might want a quiet mode and would be interested in notifications about thermal data and fan status. Regards Oliver ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 21:23 ` Oliver Neukum @ 2005-02-18 21:34 ` Pavel Machek 2005-02-18 22:00 ` Oliver Neukum 2005-02-18 21:38 ` Vojtech Pavlik 1 sibling, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 21:34 UTC (permalink / raw) To: Oliver Neukum Cc: Vojtech Pavlik, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > I wouldn't want to pass all the battery info (UPSes can be even more > > complex, able to switch on/off individual sockets, etc) through input, > > just the basic events: > > > > AC power on/off > > battery full/normal/low/critical/(fail) > > > > Then the other power-related events > > > > Lid open/closed > > Power button > > Sleep button > > What is the benefit of splitting the flow of information so? Well, if you have power button on usb keyboard -- why should it be handled differently from built-in button? > > I think that's all you need to trigger actions. You don't need the exact > > percentage of the battery, and you don't need the exact AC voltage at > > input. > > That is very debateable. I might want a quiet mode and would be > interested in notifications about thermal data and fan status. Hmm, yes, some thermal notifications are needed. OTOH I'm not sure if all the hardware does sent interrupts for temperature changes (you definitely do not get interrupts for "small" changes that do not cross trip points), and I do not see how you can do interrupts for fan status. Either fans are under Linux control (and kernel could tell you when it turns fan on/off, but...), or they do not exist from Linux's point of few. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 21:34 ` Pavel Machek @ 2005-02-18 22:00 ` Oliver Neukum 2005-02-18 23:34 ` Pavel Machek 0 siblings, 1 reply; 46+ messages in thread From: Oliver Neukum @ 2005-02-18 22:00 UTC (permalink / raw) To: Pavel Machek Cc: Vojtech Pavlik, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Am Freitag, 18. Februar 2005 22:34 schrieb Pavel Machek: > Well, if you have power button on usb keyboard -- why should it be > handled differently from built-in button? I see no reason. But that tells you that one subsystem should handle that, not which subsystem. > > > I think that's all you need to trigger actions. You don't need the exact > > > percentage of the battery, and you don't need the exact AC voltage at > > > input. > > > > That is very debateable. I might want a quiet mode and would be > > interested in notifications about thermal data and fan status. > > Hmm, yes, some thermal notifications are needed. OTOH I'm not sure if > all the hardware does sent interrupts for temperature changes (you > definitely do not get interrupts for "small" changes that do not cross I suspect that this is really done in SMI. > trip points), and I do not see how you can do interrupts for fan > status. Either fans are under Linux control (and kernel could tell you > when it turns fan on/off, but...), or they do not exist from Linux's > point of few. They still can have a readable rate, even if not under os control. Nevertheless I don't think you can reasonably define what might interest user space or not and in which detail. Regards Oliver ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 22:00 ` Oliver Neukum @ 2005-02-18 23:34 ` Pavel Machek 2005-02-18 23:51 ` Oliver Neukum 0 siblings, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 23:34 UTC (permalink / raw) To: Oliver Neukum Cc: Vojtech Pavlik, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > Well, if you have power button on usb keyboard -- why should it be > > handled differently from built-in button? > > I see no reason. But that tells you that one subsystem should handle > that, not which subsystem. If usb keyboard has power button... I do not think we really want to route that through acpi. And what if acpi is not available? (APM knows about suspend key in weird way, but not about power key). > > trip points), and I do not see how you can do interrupts for fan > > status. Either fans are under Linux control (and kernel could tell you > > when it turns fan on/off, but...), or they do not exist from Linux's > > point of few. > > They still can have a readable rate, even if not under os control. > Nevertheless I don't think you can reasonably define what might > interest user space or not and in which detail. Well, we can say that userspace definitely is interested in "power" key ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 23:34 ` Pavel Machek @ 2005-02-18 23:51 ` Oliver Neukum 2005-02-19 0:13 ` Pavel Machek 2005-02-19 1:16 ` Xavier Bestel 0 siblings, 2 replies; 46+ messages in thread From: Oliver Neukum @ 2005-02-18 23:51 UTC (permalink / raw) To: Pavel Machek Cc: Vojtech Pavlik, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Am Samstag, 19. Februar 2005 00:34 schrieb Pavel Machek: > Hi! > > > > Well, if you have power button on usb keyboard -- why should it be > > > handled differently from built-in button? > > > > I see no reason. But that tells you that one subsystem should handle > > that, not which subsystem. > > If usb keyboard has power button... I do not think we really want to > route that through acpi. And what if acpi is not available? (APM knows > about suspend key in weird way, but not about power key). I'd suggest to primarily care about acpi. The other important power management subsystems will follow suit. > > > trip points), and I do not see how you can do interrupts for fan > > > status. Either fans are under Linux control (and kernel could tell you > > > when it turns fan on/off, but...), or they do not exist from Linux's > > > point of few. > > > > They still can have a readable rate, even if not under os control. > > Nevertheless I don't think you can reasonably define what might > > interest user space or not and in which detail. > > Well, we can say that userspace definitely is interested in "power" > key ;-). I wouldn't call that selfevident. The system might be eg. a ticket vending system and we care only about wake ups from touchscreen, trackball and modem and about volume control keys. I don't think you can make up any rules about what user space is interested or not. Regards Oliver ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 23:51 ` Oliver Neukum @ 2005-02-19 0:13 ` Pavel Machek 2005-02-19 1:16 ` Xavier Bestel 1 sibling, 0 replies; 46+ messages in thread From: Pavel Machek @ 2005-02-19 0:13 UTC (permalink / raw) To: Oliver Neukum Cc: Vojtech Pavlik, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > If usb keyboard has power button... I do not think we really want to > > route that through acpi. And what if acpi is not available? (APM knows > > about suspend key in weird way, but not about power key). > > I'd suggest to primarily care about acpi. The other important power > management subsystems will follow suit. But... power key is not really a powermanagment and we do not want to have 1000 different ways "deliver info about power key into userspace". And acpi way of delivery things is not really suitable.... it mixes power key (and similar) with battery alarms etc. ACPI interface is *not* nice, lets not emulate that one. > > > > trip points), and I do not see how you can do interrupts for fan > > > > status. Either fans are under Linux control (and kernel could tell you > > > > when it turns fan on/off, but...), or they do not exist from Linux's > > > > point of few. > > > > > > They still can have a readable rate, even if not under os control. > > > Nevertheless I don't think you can reasonably define what might > > > interest user space or not and in which detail. > > > > Well, we can say that userspace definitely is interested in "power" > > key ;-). > > I wouldn't call that selfevident. The system might be eg. a ticket > vending system and we care only about wake ups from touchscreen, > trackball and modem and about volume control keys. I don't think > you can make up any rules about what user space is interested or not. Yes, maybe userspace is not interested in "space" key. In such case userland simply ignores "space" event. I do not know why "power" key should be handled in any other way. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 23:51 ` Oliver Neukum 2005-02-19 0:13 ` Pavel Machek @ 2005-02-19 1:16 ` Xavier Bestel 1 sibling, 0 replies; 46+ messages in thread From: Xavier Bestel @ 2005-02-19 1:16 UTC (permalink / raw) To: Oliver Neukum Cc: Pavel Machek, Vojtech Pavlik, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Le samedi 19 février 2005 à 00:51 +0100, Oliver Neukum a écrit : > > Well, we can say that userspace definitely is interested in "power" > > key ;-). > > I wouldn't call that selfevident. The system might be eg. a ticket > vending system and we care only about wake ups from touchscreen, > trackball and modem and about volume control keys. I don't think > you can make up any rules about what user space is interested or not. If noone can tell in advance who will be interested and what to do with it, that looks like a very good reason to go through userspace .. Xav ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 21:23 ` Oliver Neukum 2005-02-18 21:34 ` Pavel Machek @ 2005-02-18 21:38 ` Vojtech Pavlik 2005-02-18 23:31 ` Pavel Machek 2005-02-21 18:19 ` James Simmons 1 sibling, 2 replies; 46+ messages in thread From: Vojtech Pavlik @ 2005-02-18 21:38 UTC (permalink / raw) To: Oliver Neukum Cc: Pavel Machek, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, Feb 18, 2005 at 10:23:19PM +0100, Oliver Neukum wrote: > What is the benefit of splitting the flow of information so? It's split already. You get some from input (power and sleep keys on keyboards, sound volume keys and display brightness on some notebooks), some from ACPI events (power keys on notebooks and desktop cases, sound volume, display brightness on other notebooks), some from /proc/acpi/* (battery status, fan status), some from APM, from platform specific devices, from hotplug, from userspace daemons (UPS status). The question is how to unify it. Using power.c to simply pass power/sleep keys to the ACPI event pipe could get the input subsystem out of the loop at least. Maybe we could even pass sound keys to it. It's probably still the best option, though I argued for doing it the other way around - I want to know the pros and cons for all the possible approaches. > > I think that's all you need to trigger actions. You don't need the exact > > percentage of the battery, and you don't need the exact AC voltage at > > input. > > That is very debateable. I might want a quiet mode and would be > interested in notifications about thermal data and fan status. > > Regards > Oliver > -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 21:38 ` Vojtech Pavlik @ 2005-02-18 23:31 ` Pavel Machek 2005-02-19 2:58 ` Dmitry Torokhov 2005-02-21 18:19 ` James Simmons 1 sibling, 1 reply; 46+ messages in thread From: Pavel Machek @ 2005-02-18 23:31 UTC (permalink / raw) To: Vojtech Pavlik Cc: Oliver Neukum, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > What is the benefit of splitting the flow of information so? > > It's split already. You get some from input (power and sleep keys on > keyboards, sound volume keys and display brightness on some notebooks), > some from ACPI events (power keys on notebooks and desktop cases, sound > volume, display brightness on other notebooks), some from /proc/acpi/* > (battery status, fan status), some from APM, from platform specific > devices, from hotplug, from userspace daemons (UPS status). > > The question is how to unify it. > > Using power.c to simply pass power/sleep keys to the ACPI event pipe > could get the input subsystem out of the loop at least. Maybe we could > even pass sound keys to it. I do not think passing sound keys through acpi is good idea. acpid does not know how to handle them, and X already know how to get them from input subsystem. I believe power and suspend keys should definitely go through input. I'm not that sure about battery... Lid is somewhere in between... > It's probably still the best option, though I argued for doing it the > other way around - I want to know the pros and cons for all the possible > approaches. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 23:31 ` Pavel Machek @ 2005-02-19 2:58 ` Dmitry Torokhov 2005-02-19 6:28 ` Nigel Cunningham ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Dmitry Torokhov @ 2005-02-19 2:58 UTC (permalink / raw) To: Pavel Machek Cc: Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Friday 18 February 2005 18:31, Pavel Machek wrote: > Hi! > > > > What is the benefit of splitting the flow of information so? > > > > It's split already. You get some from input (power and sleep keys on > > keyboards, sound volume keys and display brightness on some notebooks), > > some from ACPI events (power keys on notebooks and desktop cases, sound > > volume, display brightness on other notebooks), some from /proc/acpi/* > > (battery status, fan status), some from APM, from platform specific > > devices, from hotplug, from userspace daemons (UPS status). > > > > The question is how to unify it. > > > > Using power.c to simply pass power/sleep keys to the ACPI event pipe > > could get the input subsystem out of the loop at least. Maybe we could > > even pass sound keys to it. > > I do not think passing sound keys through acpi is good idea. acpid > does not know how to handle them, and X already know how to get them > from input subsystem. What X? I am not saying that sound events should go through acpid, but why bringing X here? One may not even run X... > > I believe power and suspend keys should definitely go through > input. I'm not that sure about battery... Lid is somewhere in > between... > I think we need a generic way of delivering system status changes to userspace. Something like acpid but bigger than that, something not so heavily oriented on ACPI. I wonder if that kernel connector patch should be looked at. -- Dmitry ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-19 2:58 ` Dmitry Torokhov @ 2005-02-19 6:28 ` Nigel Cunningham 2005-02-19 6:53 ` Dmitry Torokhov 2005-02-21 18:11 ` James Simmons 2005-02-19 20:29 ` Pavel Machek 2005-02-19 20:31 ` Pavel Machek 2 siblings, 2 replies; 46+ messages in thread From: Nigel Cunningham @ 2005-02-19 6:28 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi. On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote: > On Friday 18 February 2005 18:31, Pavel Machek wrote: > > I believe power and suspend keys should definitely go through > > input. I'm not that sure about battery... Lid is somewhere in > > between... > I think we need a generic way of delivering system status changes to > userspace. Something like acpid but bigger than that, something not > so heavily oriented on ACPI. I wonder if that kernel connector patch > should be looked at. Absolutely. I've been thinking about this too, but haven't yet found the time to put it down on paper/email yet. I think we need a very generic system by which changes in anything remotely impacting on power management (kernelspace or userspace, including ACPI, UPS drivers, keyboard handlers, devices etc) can notify events to a userspace daemon. This daemon can act in accordance with user specified policies (changeable on the fly) to implement system level state changes (suspend to ram/disk, shutdown etc), run time power management (shutdown a USB hub that just signalled the removal of its last client), logging and so on. In some cases, it might set policy but not be actively informed of the details of the application of that policy (we don't feedback loops with a process leaving C3 to notify that it's entering C3!). This implies, of course, not just a generic way of notifying changes, but a generic way of implementing policy. Sound too ambitious, or am I thinking your thoughts after you? Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-19 6:28 ` Nigel Cunningham @ 2005-02-19 6:53 ` Dmitry Torokhov 2005-02-19 9:10 ` Nigel Cunningham 2005-02-21 18:11 ` James Simmons 1 sibling, 1 reply; 46+ messages in thread From: Dmitry Torokhov @ 2005-02-19 6:53 UTC (permalink / raw) To: ncunningham Cc: Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi Nigel, On Saturday 19 February 2005 01:28, Nigel Cunningham wrote: > Hi. > > On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote: > > On Friday 18 February 2005 18:31, Pavel Machek wrote: > > > I believe power and suspend keys should definitely go through > > > input. I'm not that sure about battery... Lid is somewhere in > > > between... > > I think we need a generic way of delivering system status changes to > > userspace. Something like acpid but bigger than that, something not > > so heavily oriented on ACPI. I wonder if that kernel connector patch > > should be looked at. > > Absolutely. I've been thinking about this too, but haven't yet found the > time to put it down on paper/email yet. > > I think we need a very generic system by which changes in anything > remotely impacting on power management (kernelspace or userspace, > including ACPI, UPS drivers, keyboard handlers, devices etc) can notify > events to a userspace daemon. This daemon can act in accordance with > user specified policies (changeable on the fly) to implement system > level state changes (suspend to ram/disk, shutdown etc), run time power > management Yep. > (shutdown a USB hub that just signalled the removal of its > last client), logging and so on. This last example - I don't think the daemon should micro-manage, I think USB bus should shutdown the hub automatically without involving userspace. > In some cases, it might set policy but > not be actively informed of the details of the application of that > policy (we don't feedback loops with a process leaving C3 to notify that > it's entering C3!). > > This implies, of course, not just a generic way of notifying changes, > but a generic way of implementing policy. > > Sound too ambitious, or am I thinking your thoughts after you? > Well, at this moment I only care about delivering the data to userspace, the rest (daemon, policies) is although interesting is out of scope for me. -- Dmitry ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-19 6:53 ` Dmitry Torokhov @ 2005-02-19 9:10 ` Nigel Cunningham 0 siblings, 0 replies; 46+ messages in thread From: Nigel Cunningham @ 2005-02-19 9:10 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi. On Sat, 2005-02-19 at 17:53, Dmitry Torokhov wrote: > Hi Nigel, > > On Saturday 19 February 2005 01:28, Nigel Cunningham wrote: > > Hi. > > > > On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote: > > > On Friday 18 February 2005 18:31, Pavel Machek wrote: > > > > I believe power and suspend keys should definitely go through > > > > input. I'm not that sure about battery... Lid is somewhere in > > > > between... > > > I think we need a generic way of delivering system status changes to > > > userspace. Something like acpid but bigger than that, something not > > > so heavily oriented on ACPI. I wonder if that kernel connector patch > > > should be looked at. > > > > Absolutely. I've been thinking about this too, but haven't yet found the > > time to put it down on paper/email yet. > > > > I think we need a very generic system by which changes in anything > > remotely impacting on power management (kernelspace or userspace, > > including ACPI, UPS drivers, keyboard handlers, devices etc) can notify > > events to a userspace daemon. This daemon can act in accordance with > > user specified policies (changeable on the fly) to implement system > > level state changes (suspend to ram/disk, shutdown etc), run time power > > management > > Yep. > > > (shutdown a USB hub that just signalled the removal of its > > last client), logging and so on. > > This last example - I don't think the daemon should micro-manage, I think > USB bus should shutdown the hub automatically without involving userspace. Yeah. Sort of contradicted what I said next, didn't I :> > > In some cases, it might set policy but > > not be actively informed of the details of the application of that > > policy (we don't feedback loops with a process leaving C3 to notify that > > it's entering C3!). > > > > This implies, of course, not just a generic way of notifying changes, > > but a generic way of implementing policy. > > > > Sound too ambitious, or am I thinking your thoughts after you? > > Well, at this moment I only care about delivering the data to userspace, > the rest (daemon, policies) is although interesting is out of scope for > me. I think we need to keep the whole picture in mind though - otherwise we might find the design is to inflexible or such like. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-19 6:28 ` Nigel Cunningham 2005-02-19 6:53 ` Dmitry Torokhov @ 2005-02-21 18:11 ` James Simmons 2005-02-21 18:34 ` Wichert Akkerman 1 sibling, 1 reply; 46+ messages in thread From: James Simmons @ 2005-02-21 18:11 UTC (permalink / raw) To: Nigel Cunningham Cc: Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List > > I think we need a generic way of delivering system status changes to > > userspace. Something like acpid but bigger than that, something not > > so heavily oriented on ACPI. I wonder if that kernel connector patch > > should be looked at. > > Absolutely. I've been thinking about this too, but haven't yet found the > time to put it down on paper/email yet. Checkout DBUS. Its very nice. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-21 18:11 ` James Simmons @ 2005-02-21 18:34 ` Wichert Akkerman 2005-02-21 21:37 ` James Simmons 0 siblings, 1 reply; 46+ messages in thread From: Wichert Akkerman @ 2005-02-21 18:34 UTC (permalink / raw) To: James Simmons Cc: Nigel Cunningham, Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Previously James Simmons wrote: > Checkout DBUS. Its very nice. D-BUS is already userspace. netlink however is a nice transport system and there are several existing tools that pass messages from netlink onto D-BUS. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-21 18:34 ` Wichert Akkerman @ 2005-02-21 21:37 ` James Simmons 2005-02-21 22:50 ` Nigel Cunningham 0 siblings, 1 reply; 46+ messages in thread From: James Simmons @ 2005-02-21 21:37 UTC (permalink / raw) To: Wichert Akkerman Cc: James Simmons, Nigel Cunningham, Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List > Previously James Simmons wrote: > > Checkout DBUS. Its very nice. > > D-BUS is already userspace. netlink however is a nice transport system > and there are several existing tools that pass messages from netlink > onto D-BUS. That is what I mean. We already have a userspace component. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-21 21:37 ` James Simmons @ 2005-02-21 22:50 ` Nigel Cunningham 2005-02-21 22:52 ` James Simmons 2005-02-21 22:54 ` Wichert Akkerman 0 siblings, 2 replies; 46+ messages in thread From: Nigel Cunningham @ 2005-02-21 22:50 UTC (permalink / raw) To: James Simmons Cc: Wichert Akkerman, James Simmons, Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Tue, 2005-02-22 at 08:37, James Simmons wrote: > > Previously James Simmons wrote: > > > Checkout DBUS. Its very nice. > > > > D-BUS is already userspace. netlink however is a nice transport system > > and there are several existing tools that pass messages from netlink > > onto D-BUS. > > That is what I mean. We already have a userspace component. I like the look of it! Looks like some work has already been done on getting kernel events out to dbus, too. Found this email: http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html Think I'll contact RML and Kay to see what the current state of play is. Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-21 22:50 ` Nigel Cunningham @ 2005-02-21 22:52 ` James Simmons 2005-02-21 22:57 ` Wichert Akkerman 2005-02-21 22:54 ` Wichert Akkerman 1 sibling, 1 reply; 46+ messages in thread From: James Simmons @ 2005-02-21 22:52 UTC (permalink / raw) To: Nigel Cunningham Cc: Wichert Akkerman, James Simmons, Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List > > > > Checkout DBUS. Its very nice. > > > > > > D-BUS is already userspace. netlink however is a nice transport system > > > and there are several existing tools that pass messages from netlink > > > onto D-BUS. > > > > That is what I mean. We already have a userspace component. > > I like the look of it! > > Looks like some work has already been done on getting kernel events out > to dbus, too. Found this email: > http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html > > Think I'll contact RML and Kay to see what the current state of play is. DBUS isthe future. I just wish they had programing howto for the average joe to write apps for it. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-21 22:52 ` James Simmons @ 2005-02-21 22:57 ` Wichert Akkerman 0 siblings, 0 replies; 46+ messages in thread From: Wichert Akkerman @ 2005-02-21 22:57 UTC (permalink / raw) To: James Simmons Cc: Nigel Cunningham, James Simmons, Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Previously James Simmons wrote: > DBUS isthe future. I just wish they had programing howto for the average > joe to write apps for it. The docs are good enough in my experience, there just seems to be a gap between the docs and the code. Strangely enough in this case there are documented API bits that are not implemented instead of the other way around as usual. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-21 22:50 ` Nigel Cunningham 2005-02-21 22:52 ` James Simmons @ 2005-02-21 22:54 ` Wichert Akkerman 1 sibling, 0 replies; 46+ messages in thread From: Wichert Akkerman @ 2005-02-21 22:54 UTC (permalink / raw) To: Nigel Cunningham Cc: James Simmons, James Simmons, Dmitry Torokhov, Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Previously Nigel Cunningham wrote: > Looks like some work has already been done on getting kernel events out > to dbus, too. Found this email: > http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html Or http://lists.freedesktop.org/archives/dbus/2005-February/002170.html or one of the few others that are there. And the answer to all of those seems to be at HAL. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-19 2:58 ` Dmitry Torokhov 2005-02-19 6:28 ` Nigel Cunningham @ 2005-02-19 20:29 ` Pavel Machek 2005-02-19 20:31 ` Pavel Machek 2 siblings, 0 replies; 46+ messages in thread From: Pavel Machek @ 2005-02-19 20:29 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > > The question is how to unify it. > > > > > > Using power.c to simply pass power/sleep keys to the ACPI event pipe > > > could get the input subsystem out of the loop at least. Maybe we could > > > even pass sound keys to it. > > > > I do not think passing sound keys through acpi is good idea. acpid > > does not know how to handle them, and X already know how to get them > > from input subsystem. > > What X? I am not saying that sound events should go through acpid, but > why bringing X here? One may not even run X... True, but X is big "existing user", thats why I mentioned it. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-19 2:58 ` Dmitry Torokhov 2005-02-19 6:28 ` Nigel Cunningham 2005-02-19 20:29 ` Pavel Machek @ 2005-02-19 20:31 ` Pavel Machek 2 siblings, 0 replies; 46+ messages in thread From: Pavel Machek @ 2005-02-19 20:31 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, Vojtech Pavlik, Oliver Neukum, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List Hi! > > I believe power and suspend keys should definitely go through > > input. I'm not that sure about battery... Lid is somewhere in > > between... > > > > I think we need a generic way of delivering system status changes to > userspace. Something like acpid but bigger than that, something not Yes, we need something like that. But IMNSHO, it should not handle power button. We already have perfectly good way of handling power button through input. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 21:38 ` Vojtech Pavlik 2005-02-18 23:31 ` Pavel Machek @ 2005-02-21 18:19 ` James Simmons 1 sibling, 0 replies; 46+ messages in thread From: James Simmons @ 2005-02-21 18:19 UTC (permalink / raw) To: Vojtech Pavlik Cc: Oliver Neukum, Pavel Machek, dtor_core, Richard Purdie, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List > > What is the benefit of splitting the flow of information so? > > It's split already. You get some from input (power and sleep keys on > keyboards, sound volume keys and display brightness on some notebooks), > some from ACPI events (power keys on notebooks and desktop cases, sound > volume, display brightness on other notebooks), some from /proc/acpi/* > (battery status, fan status), some from APM, from platform specific > devices, from hotplug, from userspace daemons (UPS status). > > The question is how to unify it. When I wrote power.c I thought there was a common power management interface. I found out I was wrong. I though the new driver model supplied a common method for power management for all platforms ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 13:26 ` Pavel Machek 2005-02-18 13:36 ` Oliver Neukum @ 2005-02-18 14:02 ` Richard Purdie 2005-02-18 14:12 ` Dmitry Torokhov 2 siblings, 0 replies; 46+ messages in thread From: Richard Purdie @ 2005-02-18 14:02 UTC (permalink / raw) To: Pavel Machek Cc: Vojtech Pavlik, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List, dmitry.torokhov Pavel Machek: > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, > and it will not work on i386/APM, anyway. I still believe right > solution is to add input interface to ACPI. /proc/acpi/events needs to > die, being replaced by input subsystem. I'm not too familiar with ACPI so I can't really comment on that. The system I'm working on only has APM. I think some attempt needs to be made to use apm if available. As i386 won't support it, lets drop the i386/APM until it does and just keep the arm case. Regards, Richard ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: 2.6: drivers/input/power.c is never built 2005-02-18 13:26 ` Pavel Machek 2005-02-18 13:36 ` Oliver Neukum 2005-02-18 14:02 ` Richard Purdie @ 2005-02-18 14:12 ` Dmitry Torokhov 2 siblings, 0 replies; 46+ messages in thread From: Dmitry Torokhov @ 2005-02-18 14:12 UTC (permalink / raw) To: Pavel Machek Cc: Richard Purdie, Vojtech Pavlik, James Simmons, Adrian Bunk, Linux Input Devices, Linux Kernel Mailing List On Fri, 18 Feb 2005 14:26:51 +0100, Pavel Machek <pavel@suse.cz> wrote: > Hi! > > > > >> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable > > >> > this option. > > >> > > >> That was written a long time ago before the new power management went > > >> in. > > >> On PDA's there is a power button and suspend button. So this was a hook > > >> so that the input layer could detect the power/suspend button being > > >> presses and then power down or turn off the device. Now that the new > > >> power > > >> management is in what should we do? > > > > > >Change power.c to generate power events like ACPI does, most likely. > > > > > > There was some recent discussion of this on linux-input. It was basically > > agreed that the input system should pass the request on to ACPI and/or apm > > and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed > > to be slightly modified to work with arm apm, the final result being: > > > > http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch > > > > I can confirm this works well on arm with apm enabled. > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI, Yes, power.c is an aggregator that transports power events from the input system into whatever power scheme is in use, so there will always be a lot of ifdefs unless we will invent grand unified power interface with userspace. I wonder if we could use kevents. > and it will not work on i386/APM, anyway. We could add fix i386 APM case but it looks like most people are concentrating on ACPI. > I still believe right > solution is to add input interface to ACPI. /proc/acpi/events needs to > die, being replaced by input subsystem. There are many more events from ACPI that are not related to input, so we need to keep it. Still, I can see buttons converted to input devices which bind to power.c and then transmit requests to acpid through /acpi/proc/event. -- Dmitry ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2005-02-21 22:57 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-02-13 0:47 2.6: drivers/input/power.c is never built Adrian Bunk 2005-02-14 18:04 ` James Simmons 2005-02-14 19:34 ` Vojtech Pavlik 2005-02-18 12:22 ` Pavel Machek 2005-02-18 13:10 ` Richard Purdie 2005-02-18 13:26 ` Pavel Machek 2005-02-18 13:36 ` Oliver Neukum 2005-02-18 16:01 ` Pavel Machek 2005-02-18 17:00 ` Vojtech Pavlik 2005-02-18 17:05 ` Oliver Neukum 2005-02-18 17:48 ` Vojtech Pavlik 2005-02-18 21:32 ` James Simmons 2005-02-18 20:14 ` Pavel Machek 2005-02-18 20:39 ` Oliver Neukum 2005-02-18 18:19 ` Dmitry Torokhov 2005-02-18 18:39 ` Vojtech Pavlik 2005-02-18 19:20 ` Dmitry Torokhov 2005-02-18 20:05 ` Vojtech Pavlik 2005-02-18 20:24 ` Pavel Machek 2005-02-18 20:40 ` Vojtech Pavlik 2005-02-18 20:59 ` Pavel Machek 2005-02-18 21:23 ` Oliver Neukum 2005-02-18 21:34 ` Pavel Machek 2005-02-18 22:00 ` Oliver Neukum 2005-02-18 23:34 ` Pavel Machek 2005-02-18 23:51 ` Oliver Neukum 2005-02-19 0:13 ` Pavel Machek 2005-02-19 1:16 ` Xavier Bestel 2005-02-18 21:38 ` Vojtech Pavlik 2005-02-18 23:31 ` Pavel Machek 2005-02-19 2:58 ` Dmitry Torokhov 2005-02-19 6:28 ` Nigel Cunningham 2005-02-19 6:53 ` Dmitry Torokhov 2005-02-19 9:10 ` Nigel Cunningham 2005-02-21 18:11 ` James Simmons 2005-02-21 18:34 ` Wichert Akkerman 2005-02-21 21:37 ` James Simmons 2005-02-21 22:50 ` Nigel Cunningham 2005-02-21 22:52 ` James Simmons 2005-02-21 22:57 ` Wichert Akkerman 2005-02-21 22:54 ` Wichert Akkerman 2005-02-19 20:29 ` Pavel Machek 2005-02-19 20:31 ` Pavel Machek 2005-02-21 18:19 ` James Simmons 2005-02-18 14:02 ` Richard Purdie 2005-02-18 14:12 ` Dmitry Torokhov
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).