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
> 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?
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
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!
> > > 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
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!
> 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
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
On Fri, 18 Feb 2005 14:26:51 +0100, Pavel Machek <[email protected]> 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
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!
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
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
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
On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <[email protected]> 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
On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote:
> On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <[email protected]> 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
On Fri, 18 Feb 2005 19:39:36 +0100, Vojtech Pavlik <[email protected]> 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 <[email protected]> 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
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
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!
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!
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
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
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!
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
> 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.
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
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!
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
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!
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!
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
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!
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
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
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
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
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
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
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
> > 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.
> > 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
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 <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
> 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.
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
> > > > 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.
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 <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
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 <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.