Trying to understand new wakeup events architecture

Trying to understand new wakeup events architecture

[Daniel Drake]

Hi,

The OLPC XO laptop suspends a lot. It suspends with the screen on as
if it is still running. It can be woken up in a variety of ways:
keyboard, mouse, WLAN, ...

While upstreaming OLPC's power management code I'm facing the
requirement that our userspace power manager needs to know the reason
for system wakeup. For example, if it was a WLAN packet then we can go
back to sleep pretty quickly, without restoring screen brightness (the
screen gets dimmed after a few mins of inactivity on the
keyboard/mouse front). But if the system was woken up with the
keyboard we want to restore screen brightness immediately and stay
awake for a longer time before going back into suspend.

We used to do this (outside of mainline) with a /proc node storing the
"wakeup reason" but I'm now wondering what the most upstream-suitable
approach is.

I saw this patch:

commit 074037ec79bea73edf1b1ec72fef1010e83e3cc5
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Sep 22 22:09:10 2010 +0200

    PM / Wakeup: Introduce wakeup source objects and event statistics

But I'm unable to find any documentation of what it's for or how to use it.

Does it solve my problem?
If so, are there any examples of drivers adapted to use this
functionality? Or documentation?

I suspect the reason I don't understand it well is because I haven't
read 17 long threads about android...And I'd rather not, if it can be
avoided :)

Thanks,
Daniel

Re: Trying to understand new wakeup events architecture

[Rafael J. Wysocki]

On Tuesday, December 14, 2010, Daniel Drake wrote:
> Hi,
> 
> The OLPC XO laptop suspends a lot. It suspends with the screen on as
> if it is still running. It can be woken up in a variety of ways:
> keyboard, mouse, WLAN, ...
> 
> While upstreaming OLPC's power management code I'm facing the
> requirement that our userspace power manager needs to know the reason
> for system wakeup. For example, if it was a WLAN packet then we can go
> back to sleep pretty quickly, without restoring screen brightness (the
> screen gets dimmed after a few mins of inactivity on the
> keyboard/mouse front). But if the system was woken up with the
> keyboard we want to restore screen brightness immediately and stay
> awake for a longer time before going back into suspend.
> 
> We used to do this (outside of mainline) with a /proc node storing the
> "wakeup reason" but I'm now wondering what the most upstream-suitable
> approach is.
> 
> I saw this patch:
> 
> commit 074037ec79bea73edf1b1ec72fef1010e83e3cc5
> Author: Rafael J. Wysocki <rjw@sisk.pl>
> Date:   Wed Sep 22 22:09:10 2010 +0200
> 
>     PM / Wakeup: Introduce wakeup source objects and event statistics
> 
> But I'm unable to find any documentation of what it's for or how to use it.
> 
> Does it solve my problem?
> If so, are there any examples of drivers adapted to use this
> functionality? Or documentation?
> 
> I suspect the reason I don't understand it well is because I haven't
> read 17 long threads about android...And I'd rather not, if it can be
> avoided :)

I guess it's sufficient to read the article at http://lwn.net/Articles/416690/
(or the PDF linked from there is that's not enough :-)).

I don't really think it solves your problem right now, because it's only a
high-level framework and it's missing some mechanics for this purpose.

In principle you could compare device wakeup counters before suspend
and after resume and figure out what devices reported wakeup in the
meantime from that.  For devices, the counters may be read from sysfs.
For "raw" wakeup sources it's necessary to read the wakeup_sources file in
debugfs.

Still, you need your subsystems to call pm_wakeup_event() or pm_stay_awake()
during resume to actually report the events. 

Thanks,
Rafael

Re: Trying to understand new wakeup events architecture

[Daniel Drake]

On 15 December 2010 22:33, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> I guess it's sufficient to read the article at http://lwn.net/Articles/416690/
> (or the PDF linked from there is that's not enough :-)).

Thanks, that helps a lot.

> I don't really think it solves your problem right now, because it's only a
> high-level framework and it's missing some mechanics for this purpose.

OK, so we'll push for a sysfs node that can be used by userspace to
determine the wakeup source.

The article is very interesting, there's certainly a great crossover
with OLPC's "idle-suspend" which is essentially the same thing.
However we have various problems with the current implementation,
meaning that most deployments turn it off. Looks like you are taking
steps to address some of those, I'll try and put some time in this
direction in future.

Daniel

Re: Trying to understand new wakeup events architecture

[Daniel Drake]

Hi Rafael,

On 16 December 2010 14:39, Daniel Drake <dsd@laptop.org> wrote:
> On 15 December 2010 22:33, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> I guess it's sufficient to read the article at http://lwn.net/Articles/416690/
>> (or the PDF linked from there is that's not enough :-)).
>
> Thanks, that helps a lot.
>
>> I don't really think it solves your problem right now, because it's only a
>> high-level framework and it's missing some mechanics for this purpose.
>
> OK, so we'll push for a sysfs node that can be used by userspace to
> determine the wakeup source.

How do you feel about us using power_kobj to create
/sys/power/wakeup_source from inside our OLPC code?
This would include a textual representation of the last wakeup source.

Alternatively we could put it as a sysfs attribute of our own platform device.

Thanks,
Daniel

Re: Trying to understand new wakeup events architecture

[Rafael J. Wysocki]

On Wednesday, January 12, 2011, Daniel Drake wrote:
> Hi Rafael,
> 
> On 16 December 2010 14:39, Daniel Drake <dsd@laptop.org> wrote:
> > On 15 December 2010 22:33, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> I guess it's sufficient to read the article at http://lwn.net/Articles/416690/
> >> (or the PDF linked from there is that's not enough :-)).
> >
> > Thanks, that helps a lot.
> >
> >> I don't really think it solves your problem right now, because it's only a
> >> high-level framework and it's missing some mechanics for this purpose.
> >
> > OK, so we'll push for a sysfs node that can be used by userspace to
> > determine the wakeup source.
> 
> How do you feel about us using power_kobj to create
> /sys/power/wakeup_source from inside our OLPC code?
> This would include a textual representation of the last wakeup source.
> 
> Alternatively we could put it as a sysfs attribute of our own platform device.

I'm basically fine with /sys/power/source as long as its contents are generally
suitable.  What exactly do you want to show up in that file?

Rafael

Re: Trying to understand new wakeup events architecture

[Daniel Drake]

On Wed, 2011-01-12 at 21:02 +0100, Rafael J. Wysocki wrote:
> > How do you feel about us using power_kobj to create
> > /sys/power/wakeup_source from inside our OLPC code?
> > This would include a textual representation of the last wakeup source.
> > 
> > Alternatively we could put it as a sysfs attribute of our own platform device.
> 
> I'm basically fine with /sys/power/source as long as its contents are generally
> suitable.  What exactly do you want to show up in that file?

Do you mean /sys/power/source or /sys/power/wakeup_source? I prefer the
latter as the first one sounds like "power source" (AC, battery,
solar, ...)

As for contents, it will read back a string. One of:

rtc alarm
power button
lid
key press
battery
battery state changed
battery error
ebook
wlan packet
ac power
battery critical
gp timer
hda
usb
unknown

Thanks,
Daniel

Re: Trying to understand new wakeup events architecture

[Alan Stern]

On Thu, 13 Jan 2011, Daniel Drake wrote:

> As for contents, it will read back a string. One of:
> 
> rtc alarm
> power button
> lid
> key press
> battery
> battery state changed
> battery error
> ebook
> wlan packet
> ac power
> battery critical
> gp timer
> hda
> usb
> unknown

Wouldn't it be better to read back a device pathname when the wakeup
source can be identified as a particular device?  Whoever uses this 
field should be responsible for converting it to one of those more 
generic forms.

Alan Stern

Re: Trying to understand new wakeup events architecture

[Daniel Drake]

On Thu, 2011-01-13 at 10:14 -0500, Alan Stern wrote:
> On Thu, 13 Jan 2011, Daniel Drake wrote:
> 
> > As for contents, it will read back a string. One of:
> > 
> > rtc alarm
> > power button
> > lid
> > key press
> > battery
> > battery state changed
> > battery error
> > ebook
> > wlan packet
> > ac power
> > battery critical
> > gp timer
> > hda
> > usb
> > unknown
> 
> Wouldn't it be better to read back a device pathname when the wakeup
> source can be identified as a particular device?  Whoever uses this 
> field should be responsible for converting it to one of those more 
> generic forms.

It could be done, but might be ugly. The problem is that those
individual devices don't really know that they were woken up. It's done
by OLPC's EC driver. So the EC driver would have to either hardcode
device paths, or have a load of device-hunting code.

Another small problem is that it doesn't encode the difference between
"battery state changed" and "battery error", for example.

If it's really disliked as a string, perhaps it would be OK just to
stash it within the sysfs directory of our device, not polluting the
global namespace.

I'm hoping this can all be a temporary measure anyway, as future closer
integration with Rafael's wakeup events architecture plus the ability
for that architecture to export wakeup source info should make it go
away.

Daniel

Re: Trying to understand new wakeup events architecture

[Alan Stern]

On Thu, 13 Jan 2011, Daniel Drake wrote:

> On Thu, 2011-01-13 at 10:14 -0500, Alan Stern wrote:
> > On Thu, 13 Jan 2011, Daniel Drake wrote:
> > 
> > > As for contents, it will read back a string. One of:
> > > 
> > > rtc alarm
> > > power button
> > > lid
> > > key press
> > > battery
> > > battery state changed
> > > battery error
> > > ebook
> > > wlan packet
> > > ac power
> > > battery critical
> > > gp timer
> > > hda
> > > usb
> > > unknown
> > 
> > Wouldn't it be better to read back a device pathname when the wakeup
> > source can be identified as a particular device?  Whoever uses this 
> > field should be responsible for converting it to one of those more 
> > generic forms.
> 
> It could be done, but might be ugly. The problem is that those
> individual devices don't really know that they were woken up. It's done
> by OLPC's EC driver. So the EC driver would have to either hardcode
> device paths, or have a load of device-hunting code.
> 
> Another small problem is that it doesn't encode the difference between
> "battery state changed" and "battery error", for example.
> 
> If it's really disliked as a string, perhaps it would be OK just to
> stash it within the sysfs directory of our device, not polluting the
> global namespace.
> 
> I'm hoping this can all be a temporary measure anyway, as future closer
> integration with Rafael's wakeup events architecture plus the ability
> for that architecture to export wakeup source info should make it go
> away.

You can do whatever is best for you on the OLPC platform; I was just 
offering a suggestion.

Alan Stern

Re: Trying to understand new wakeup events architecture

[Rafael J. Wysocki]

On Thursday, January 13, 2011, Alan Stern wrote:
> On Thu, 13 Jan 2011, Daniel Drake wrote:
> 
> > On Thu, 2011-01-13 at 10:14 -0500, Alan Stern wrote:
> > > On Thu, 13 Jan 2011, Daniel Drake wrote:
> > > 
> > > > As for contents, it will read back a string. One of:
> > > > 
> > > > rtc alarm
> > > > power button
> > > > lid
> > > > key press
> > > > battery
> > > > battery state changed
> > > > battery error
> > > > ebook
> > > > wlan packet
> > > > ac power
> > > > battery critical
> > > > gp timer
> > > > hda
> > > > usb
> > > > unknown
> > > 
> > > Wouldn't it be better to read back a device pathname when the wakeup
> > > source can be identified as a particular device?  Whoever uses this 
> > > field should be responsible for converting it to one of those more 
> > > generic forms.
> > 
> > It could be done, but might be ugly. The problem is that those
> > individual devices don't really know that they were woken up. It's done
> > by OLPC's EC driver. So the EC driver would have to either hardcode
> > device paths, or have a load of device-hunting code.

Alternatively, it could store the information somewhere and have some special
code down the resume code path turn it into the info available from sysfs.

> > Another small problem is that it doesn't encode the difference between
> > "battery state changed" and "battery error", for example.
> > 
> > If it's really disliked as a string, perhaps it would be OK just to
> > stash it within the sysfs directory of our device, not polluting the
> > global namespace.
> > 
> > I'm hoping this can all be a temporary measure anyway, as future closer
> > integration with Rafael's wakeup events architecture plus the ability
> > for that architecture to export wakeup source info should make it go
> > away.

Well, if that's supposed to be temporary, it shouldn't be there in
/sys/power/, so please put it somewhere else in that case.

> You can do whatever is best for you on the OLPC platform; I was just 
> offering a suggestion.

It looks like Daniel wants the wakeup events framework to store the last
active wakeup source information somewhere (eg. in a file in /sys/power).
I'm a little bit worried about that, because potentially there may be many
wakeup events occuring at run time, in which case it would be a significant
performance overhead to update the "last active wakeup source" info every
time (and a scalability issue, because every code path handling a wakeup
source would want to update the same sysfs file).  Also, collecting that
information at run time doesn't seem to be particularly useful.

It may be useful to know what device has actually woken up the system from
suspend.  To that end, I think the only really valid approach is to retrieve
this information from the platform firmware early during resume and export
it through a sysfs attribute afterwards.  We can develop a generic helper
code for that second part, but the first one has to be platform-specific.

Daniel, what exactly does your user space use this information for?

Thanks,
Rafael

Re: Trying to understand new wakeup events architecture

[Daniel Drake]

On Thu, 2011-01-13 at 20:34 +0100, Rafael J. Wysocki wrote:
> It looks like Daniel wants the wakeup events framework to store the last
> active wakeup source information somewhere (eg. in a file in /sys/power).
> I'm a little bit worried about that, because potentially there may be many
> wakeup events occuring at run time, in which case it would be a significant
> performance overhead to update the "last active wakeup source" info every
> time (and a scalability issue, because every code path handling a wakeup
> source would want to update the same sysfs file).  Also, collecting that
> information at run time doesn't seem to be particularly useful.

This was one thing that confused me reading about the wakeup events
architecture, and I'm still not entirely clear.

Your definition of "wakeup event" is an event that happens, during
regular system operation, that should prevent the system from going to
sleep. Is that accurate?

When I refer to "wakeup event" I'm referring exclusively to events that
happen when the system is suspended, that cause it to wake up and resume
operation.

> It may be useful to know what device has actually woken up the system from
> suspend.  To that end, I think the only really valid approach is to retrieve
> this information from the platform firmware early during resume and export
> it through a sysfs attribute afterwards.  We can develop a generic helper
> code for that second part, but the first one has to be platform-specific.
> 
> Daniel, what exactly does your user space use this information for?

We're talking the same language here. I'd welcome a generic helper.

There are several different cases, but here is one example that should
be illustrative:

1) System is idle, hence it goes to sleep with display on, with rtcwake
timer for 5 minutes in the future, as well as various other wakeup
sources active (keyboard, mouse, network, ...)

2) 5 minutes passes and system resumes. Userspace determines that the
wakeup source was the RTC alarm. In other words, the system is still
idle. Since the user doesn't seem to be doing anything and might not
even be watching, we dim the screen a bit to save some power. Then we go
back to sleep.

3) A few minutes later, the user starts typing. The system resumes.
Userspace checks the wakeup reason, notes that it was woken up due to
local user activity. So the display is restored to normal brightness.
The idle-check timer is started again, ready to go to sleep a minute or
so after user inactivity.




an alternative case for #3 is:

3b) A few minutes later, a network packet is received for the system.
The system resumes. Userspace checks the wakeup reason, notes that it
was woken up due to network activity. The brightness is *not* changed,
since if it were, it would appear very strange to anyone watching. The
system goes back to sleep within a few seconds, assuming that the user
is not present means that theres no need to sit around a long time
waiting for input.


Daniel

Re: Trying to understand new wakeup events architecture

[Alan Stern]

On Thu, 13 Jan 2011, Daniel Drake wrote:

> On Thu, 2011-01-13 at 20:34 +0100, Rafael J. Wysocki wrote:
> > It looks like Daniel wants the wakeup events framework to store the last
> > active wakeup source information somewhere (eg. in a file in /sys/power).
> > I'm a little bit worried about that, because potentially there may be many
> > wakeup events occuring at run time, in which case it would be a significant
> > performance overhead to update the "last active wakeup source" info every
> > time (and a scalability issue, because every code path handling a wakeup
> > source would want to update the same sysfs file).  Also, collecting that
> > information at run time doesn't seem to be particularly useful.
> 
> This was one thing that confused me reading about the wakeup events
> architecture, and I'm still not entirely clear.
> 
> Your definition of "wakeup event" is an event that happens, during
> regular system operation, that should prevent the system from going to
> sleep. Is that accurate?

My understanding (which probably isn't exactly the same as Rafael's) is
that a "wakeup event" is any event which should either prevent the
system from going to sleep or should wake up the system if it is
already asleep.  After all, these are the same events (user typing,
network packet arriving, alarm firing) -- the only difference is what
state the system is in when they occur.

> When I refer to "wakeup event" I'm referring exclusively to events that
> happen when the system is suspended, that cause it to wake up and resume
> operation.
> 
> > It may be useful to know what device has actually woken up the system from
> > suspend.  To that end, I think the only really valid approach is to retrieve
> > this information from the platform firmware early during resume and export
> > it through a sysfs attribute afterwards.  We can develop a generic helper
> > code for that second part, but the first one has to be platform-specific.
> > 
> > Daniel, what exactly does your user space use this information for?
> 
> We're talking the same language here. I'd welcome a generic helper.
> 
> There are several different cases, but here is one example that should
> be illustrative:
> 
> 1) System is idle, hence it goes to sleep with display on, with rtcwake
> timer for 5 minutes in the future, as well as various other wakeup
> sources active (keyboard, mouse, network, ...)
> 
> 2) 5 minutes passes and system resumes. Userspace determines that the
> wakeup source was the RTC alarm. In other words, the system is still
> idle. Since the user doesn't seem to be doing anything and might not
> even be watching, we dim the screen a bit to save some power. Then we go
> back to sleep.
> 
> 3) A few minutes later, the user starts typing. The system resumes.
> Userspace checks the wakeup reason, notes that it was woken up due to
> local user activity. So the display is restored to normal brightness.
> The idle-check timer is started again, ready to go to sleep a minute or
> so after user inactivity.

What happens when the system wakes up because more than one event 
happened?  For example, what if the user starts typing at exactly the 
same moment as the 5-minute RTC alarm fires?  What if a network packet 
is also received at that same moment?

Alan Stern

Re: Trying to understand new wakeup events architecture

[Daniel Drake]

On Thu, 2011-01-13 at 15:31 -0500, Alan Stern wrote:
> On Thu, 13 Jan 2011, Daniel Drake wrote:
> 
> > On Thu, 2011-01-13 at 20:34 +0100, Rafael J. Wysocki wrote:
> > > It looks like Daniel wants the wakeup events framework to store the last
> > > active wakeup source information somewhere (eg. in a file in /sys/power).
> > > I'm a little bit worried about that, because potentially there may be many
> > > wakeup events occuring at run time, in which case it would be a significant
> > > performance overhead to update the "last active wakeup source" info every
> > > time (and a scalability issue, because every code path handling a wakeup
> > > source would want to update the same sysfs file).  Also, collecting that
> > > information at run time doesn't seem to be particularly useful.
> > 
> > This was one thing that confused me reading about the wakeup events
> > architecture, and I'm still not entirely clear.
> > 
> > Your definition of "wakeup event" is an event that happens, during
> > regular system operation, that should prevent the system from going to
> > sleep. Is that accurate?
> 
> My understanding (which probably isn't exactly the same as Rafael's) is
> that a "wakeup event" is any event which should either prevent the
> system from going to sleep or should wake up the system if it is
> already asleep.  After all, these are the same events (user typing,
> network packet arriving, alarm firing) -- the only difference is what
> state the system is in when they occur.

OK, that makes it clearer.

> > When I refer to "wakeup event" I'm referring exclusively to events that
> > happen when the system is suspended, that cause it to wake up and resume
> > operation.
> > 
> > > It may be useful to know what device has actually woken up the system from
> > > suspend.  To that end, I think the only really valid approach is to retrieve
> > > this information from the platform firmware early during resume and export
> > > it through a sysfs attribute afterwards.  We can develop a generic helper
> > > code for that second part, but the first one has to be platform-specific.
> > > 
> > > Daniel, what exactly does your user space use this information for?
> > 
> > We're talking the same language here. I'd welcome a generic helper.
> > 
> > There are several different cases, but here is one example that should
> > be illustrative:
> > 
> > 1) System is idle, hence it goes to sleep with display on, with rtcwake
> > timer for 5 minutes in the future, as well as various other wakeup
> > sources active (keyboard, mouse, network, ...)
> > 
> > 2) 5 minutes passes and system resumes. Userspace determines that the
> > wakeup source was the RTC alarm. In other words, the system is still
> > idle. Since the user doesn't seem to be doing anything and might not
> > even be watching, we dim the screen a bit to save some power. Then we go
> > back to sleep.
> > 
> > 3) A few minutes later, the user starts typing. The system resumes.
> > Userspace checks the wakeup reason, notes that it was woken up due to
> > local user activity. So the display is restored to normal brightness.
> > The idle-check timer is started again, ready to go to sleep a minute or
> > so after user inactivity.
> 
> What happens when the system wakes up because more than one event 
> happened?  For example, what if the user starts typing at exactly the 
> same moment as the 5-minute RTC alarm fires? 

I think there is some guarantee that the wakeup source is identifiable.
One of those things has to have happened first, even if they were very
close in time. If it was the keyboard waking up in #2, the keyboard is
presented as the wakeup reason, and the system decides to keep running
for a while, restarting its user inactivity timer for the next suspend
(where we go back to #1).

If the RTC alarm wakes the system but then there is a keypress during
resume, this will get caught by a userspace daemon, returning the system
to "normal state" with the user inactivity timer. If it happens as the
system is going into suspend, the system will go into suspend then will
cause a new immediate system resume with the keyboard identified as the
wakeup source.

There may be some race conditions here, which Rafael's recent
infrastructure work may be on the road to fixing.

Daniel

Re: Trying to understand new wakeup events architecture

[Paul Fox]

daniel wrote:
 > On Thu, 2011-01-13 at 15:31 -0500, Alan Stern wrote:
 > > On Thu, 13 Jan 2011, Daniel Drake wrote:
 > > 
 > > > On Thu, 2011-01-13 at 20:34 +0100, Rafael J. Wysocki wrote:
 > > > > It looks like Daniel wants the wakeup events framework to store the last
 > > > > active wakeup source information somewhere (eg. in a file in /sys/power).
 > > > > I'm a little bit worried about that, because potentially there may be many
 > > > > wakeup events occuring at run time, in which case it would be a significant
 > > > > performance overhead to update the "last active wakeup source" info every
 > > > > time (and a scalability issue, because every code path handling a wakeup
 > > > > source would want to update the same sysfs file).  Also, collecting that
 > > > > information at run time doesn't seem to be particularly useful.
 > > > 
 > > > This was one thing that confused me reading about the wakeup events
 > > > architecture, and I'm still not entirely clear.
 > > > 
 > > > Your definition of "wakeup event" is an event that happens, during
 > > > regular system operation, that should prevent the system from going to
 > > > sleep. Is that accurate?
 > > 
 > > My understanding (which probably isn't exactly the same as Rafael's) is
 > > that a "wakeup event" is any event which should either prevent the
 > > system from going to sleep or should wake up the system if it is
 > > already asleep.  After all, these are the same events (user typing,
 > > network packet arriving, alarm firing) -- the only difference is what
 > > state the system is in when they occur.
 > 
 > OK, that makes it clearer.
 > 
 > > > When I refer to "wakeup event" I'm referring exclusively to events that
 > > > happen when the system is suspended, that cause it to wake up and resume
 > > > operation.
 > > > 
 > > > > It may be useful to know what device has actually woken up the system from
 > > > > suspend.  To that end, I think the only really valid approach is to retrieve
 > > > > this information from the platform firmware early during resume and export
 > > > > it through a sysfs attribute afterwards.  We can develop a generic helper
 > > > > code for that second part, but the first one has to be platform-specific.
 > > > > 
 > > > > Daniel, what exactly does your user space use this information for?
 > > > 
 > > > We're talking the same language here. I'd welcome a generic helper.
 > > > 
 > > > There are several different cases, but here is one example that should
 > > > be illustrative:
 > > > 
 > > > 1) System is idle, hence it goes to sleep with display on, with rtcwake
 > > > timer for 5 minutes in the future, as well as various other wakeup
 > > > sources active (keyboard, mouse, network, ...)
 > > > 
 > > > 2) 5 minutes passes and system resumes. Userspace determines that the
 > > > wakeup source was the RTC alarm. In other words, the system is still
 > > > idle. Since the user doesn't seem to be doing anything and might not
 > > > even be watching, we dim the screen a bit to save some power. Then we go
 > > > back to sleep.
 > > > 
 > > > 3) A few minutes later, the user starts typing. The system resumes.
 > > > Userspace checks the wakeup reason, notes that it was woken up due to
 > > > local user activity. So the display is restored to normal brightness.
 > > > The idle-check timer is started again, ready to go to sleep a minute or
 > > > so after user inactivity.
 > > 
 > > What happens when the system wakes up because more than one event 
 > > happened?  For example, what if the user starts typing at exactly the 
 > > same moment as the 5-minute RTC alarm fires? 
 > 
 > I think there is some guarantee that the wakeup source is identifiable.
 > One of those things has to have happened first, even if they were very
 > close in time. If it was the keyboard waking up in #2, the keyboard is
 > presented as the wakeup reason, and the system decides to keep running
 > for a while, restarting its user inactivity timer for the next suspend
 > (where we go back to #1).
 > 
 > If the RTC alarm wakes the system but then there is a keypress during
 > resume, this will get caught by a userspace daemon, returning the system
 > to "normal state" with the user inactivity timer. If it happens as the
 > system is going into suspend, the system will go into suspend then will
 > cause a new immediate system resume with the keyboard identified as the
 > wakeup source.
 > 
 > There may be some race conditions here, which Rafael's recent
 > infrastructure work may be on the road to fixing.

there are certainly race conditions there on the XO.  in practice,
they haven't been too serious, since the primary wakeup source is user
input, and users simply retry.  but our wlan, for example, isn't as
peristent about waking the system, and if we miss one of those events,
it can mean the machine loses active connections (unless woken in time
by other means).  i've seen other clear examples during powerd
development, and have had to redesign some system interactions to
reduce the chances of such races.  it's very clear that the new
infrastructure will be a big improvement.

paul

 > 
 > Daniel
 > 

=---------------------
 paul fox, pgf@laptop.org