On Tuesday, May 12, 2015 12:12:30 AM Pavel Machek wrote:
> Hi!
>
> > > If the event was user-triggered it sends
> > > out a DBus signal announcing the end of the suspend, Chrome thaws its
> > > renderer processes, the full UI comes back up, and the user can start
> > > working. If the event was
Hi!
> > If the event was user-triggered it sends
> > out a DBus signal announcing the end of the suspend, Chrome thaws its
> > renderer processes, the full UI comes back up, and the user can start
> > working. If the event was _not_ user-triggred (if it was the RTC or
> > NIC), the power manager
Hi!
If the event was user-triggered it sends
out a DBus signal announcing the end of the suspend, Chrome thaws its
renderer processes, the full UI comes back up, and the user can start
working. If the event was _not_ user-triggred (if it was the RTC or
NIC), the power manager sends out
On Tuesday, May 12, 2015 12:12:30 AM Pavel Machek wrote:
Hi!
If the event was user-triggered it sends
out a DBus signal announcing the end of the suspend, Chrome thaws its
renderer processes, the full UI comes back up, and the user can start
working. If the event was _not_
On 05/07/2015 11:03 PM, Rafael J. Wysocki wrote:
> On Thursday, May 07, 2015 05:54:56 PM One Thousand Gnomes wrote:
>> On Tue, 05 May 2015 14:31:26 +0200
>>
>>> For example, when you wake up from S3 on ACPI-based systems, the best you
>>> can get is what devices have generated the wakeup events,
On 05/07/2015 11:03 PM, Rafael J. Wysocki wrote:
On Thursday, May 07, 2015 05:54:56 PM One Thousand Gnomes wrote:
On Tue, 05 May 2015 14:31:26 +0200
For example, when you wake up from S3 on ACPI-based systems, the best you
can get is what devices have generated the wakeup events, but there's
On Wednesday, May 06, 2015 10:40:53 AM Chirantan Ekbote wrote:
> On Tue, May 5, 2015 at 4:47 PM, Rafael J. Wysocki wrote:
> > On Monday, May 04, 2015 04:30:00 PM Chirantan Ekbote wrote:
> >
> >
> >
> >> Ok so now I can talk about how lucid sleep fits into all of this. The
> >> power manager
On Thursday, May 07, 2015 05:54:56 PM One Thousand Gnomes wrote:
> On Tue, 05 May 2015 14:31:26 +0200
>
> > For example, when you wake up from S3 on ACPI-based systems, the best you
> > can get is what devices have generated the wakeup events, but there's
> > no input available from that (like
On Thu, May 7, 2015 at 10:03 AM, One Thousand Gnomes
wrote:
>> You are, of course, correct. Ultimately the only requirement we have
>> is that there exists a way for userspace to determine if the system
>> woke up because of a user-triggered event. The actual mechanism by
>
> No. That is
> You are, of course, correct. Ultimately the only requirement we have
> is that there exists a way for userspace to determine if the system
> woke up because of a user-triggered event. The actual mechanism by
No. That is irrelevant. You need a way to ascertain if a user triggered
event has
On Tue, 05 May 2015 14:31:26 +0200
> For example, when you wake up from S3 on ACPI-based systems, the best you
> can get is what devices have generated the wakeup events, but there's
> no input available from that (like you won't know which key has been
> pressed). You may not get that even.
On Thu, May 7, 2015 at 10:03 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
You are, of course, correct. Ultimately the only requirement we have
is that there exists a way for userspace to determine if the system
woke up because of a user-triggered event. The actual mechanism by
On Thursday, May 07, 2015 05:54:56 PM One Thousand Gnomes wrote:
On Tue, 05 May 2015 14:31:26 +0200
For example, when you wake up from S3 on ACPI-based systems, the best you
can get is what devices have generated the wakeup events, but there's
no input available from that (like you won't
On Wednesday, May 06, 2015 10:40:53 AM Chirantan Ekbote wrote:
On Tue, May 5, 2015 at 4:47 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, May 04, 2015 04:30:00 PM Chirantan Ekbote wrote:
snip
Ok so now I can talk about how lucid sleep fits into all of this. The
power
You are, of course, correct. Ultimately the only requirement we have
is that there exists a way for userspace to determine if the system
woke up because of a user-triggered event. The actual mechanism by
No. That is irrelevant. You need a way to ascertain if a user triggered
event has
On Tue, 05 May 2015 14:31:26 +0200
For example, when you wake up from S3 on ACPI-based systems, the best you
can get is what devices have generated the wakeup events, but there's
no input available from that (like you won't know which key has been
pressed). You may not get that even. You
On Tue, May 5, 2015 at 4:47 PM, Rafael J. Wysocki wrote:
> On Monday, May 04, 2015 04:30:00 PM Chirantan Ekbote wrote:
>
>
>
>> Ok so now I can talk about how lucid sleep fits into all of this. The
>> power manager only considers a suspend attempt successful if the write
>> to /sys/power/state
On Tue, 2015-05-05 at 12:22 -0700, Chirantan Ekbote wrote:
> On Tue, May 5, 2015 at 3:46 AM, Bastien Nocera
> wrote:
> >
> > > The last thing the power manager does, right before
> > > writing "mem" to /sys/power/state, is write the wakeup_count
> > > that it
> > > read earlier to
On Tue, 2015-05-05 at 12:22 -0700, Chirantan Ekbote wrote:
On Tue, May 5, 2015 at 3:46 AM, Bastien Nocera had...@hadess.net
wrote:
The last thing the power manager does, right before
writing mem to /sys/power/state, is write the wakeup_count
that it
read earlier to
On Tue, May 5, 2015 at 4:47 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, May 04, 2015 04:30:00 PM Chirantan Ekbote wrote:
snip
Ok so now I can talk about how lucid sleep fits into all of this. The
power manager only considers a suspend attempt successful if the write
to
On Wed, May 6, 2015 at 1:38 AM, David Lang wrote:
> On Wed, 6 May 2015, Rafael J. Wysocki wrote:
>
>>> You are, of course, correct. Ultimately the only requirement we have
>>> is that there exists a way for userspace to determine if the system
>>> woke up because of a user-triggered event. The
On Wed, 6 May 2015, Rafael J. Wysocki wrote:
You are, of course, correct. Ultimately the only requirement we have
is that there exists a way for userspace to determine if the system
woke up because of a user-triggered event. The actual mechanism by
which this determination is made isn't
On Tuesday, May 05, 2015 01:58:12 PM Chirantan Ekbote wrote:
> On Tue, May 5, 2015 at 12:35 PM, Alan Stern wrote:
> > On Tue, 5 May 2015, Chirantan Ekbote wrote:
> >
> >> This is our plan for the next version (see my email earlier in this
> >> thread). Keeping a hybrid power state with hacks in
On Monday, May 04, 2015 04:30:00 PM Chirantan Ekbote wrote:
> On Mon, May 4, 2015 at 3:12 PM, Rafael J. Wysocki wrote:
> > On Thursday, April 30, 2015 11:54:51 AM Chirantan Ekbote wrote:
> >> On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
> >> > Hi,
> >> >
> >> > On Thu, Apr 30, 2015 at
On Tue, May 5, 2015 at 12:35 PM, Alan Stern wrote:
> On Tue, 5 May 2015, Chirantan Ekbote wrote:
>
>> This is our plan for the next version (see my email earlier in this
>> thread). Keeping a hybrid power state with hacks in the drivers isn't
>> really maintainable, scalable, or upstream-able
On Tue, 5 May 2015, Chirantan Ekbote wrote:
> This is our plan for the next version (see my email earlier in this
> thread). Keeping a hybrid power state with hacks in the drivers isn't
> really maintainable, scalable, or upstream-able and has caused us some
> headaches already. Unfortunately
On Tue, May 5, 2015 at 3:46 AM, Bastien Nocera wrote:
> On Mon, 2015-05-04 at 16:30 -0700, Chirantan Ekbote wrote:
>>
>
>> In the interest of brevity, I didn't go into the design of suspend /
>> resume in userspace in my last email but it seems like there's no way
>> around it.
>>
>> Ignoring
On Tue, May 5, 2015 at 7:39 AM, Alan Stern wrote:
> On Mon, 4 May 2015, Chirantan Ekbote wrote:
>
>> Ok so now I can talk about how lucid sleep fits into all of this. The
>> power manager only considers a suspend attempt successful if the write
>> to /sys/power/state was successful. If the
On Mon, 4 May 2015, Chirantan Ekbote wrote:
> Ok so now I can talk about how lucid sleep fits into all of this. The
> power manager only considers a suspend attempt successful if the write
> to /sys/power/state was successful. If the suspend was successful,
> the power manager then reads
On Tuesday, May 05, 2015 08:05:32 AM Tomeu Vizoso wrote:
> On 5 May 2015 at 00:19, Rafael J. Wysocki wrote:
> > On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
> >> On 30 April 2015 at 20:54, Chirantan Ekbote wrote:
> >> > On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
> >> >>
On Mon, 2015-05-04 at 16:30 -0700, Chirantan Ekbote wrote:
>
> In the interest of brevity, I didn't go into the design of suspend /
> resume in userspace in my last email but it seems like there's no way
> around it.
>
> Ignoring lucid sleep for a moment, here is how a regular suspend
> works
On 5 May 2015 at 00:19, Rafael J. Wysocki wrote:
> On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
>> On 30 April 2015 at 20:54, Chirantan Ekbote wrote:
>> > On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
>> >> Hi,
>> >>
>> >> On Thu, Apr 30, 2015 at 10:10 AM, John Stultz
>>
On Tuesday, May 05, 2015 08:05:32 AM Tomeu Vizoso wrote:
On 5 May 2015 at 00:19, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
On 30 April 2015 at 20:54, Chirantan Ekbote chiran...@chromium.org wrote:
On Thu, Apr 30, 2015 at 10:23 AM,
On Monday, May 04, 2015 04:30:00 PM Chirantan Ekbote wrote:
On Mon, May 4, 2015 at 3:12 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, April 30, 2015 11:54:51 AM Chirantan Ekbote wrote:
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu,
On Wed, 6 May 2015, Rafael J. Wysocki wrote:
You are, of course, correct. Ultimately the only requirement we have
is that there exists a way for userspace to determine if the system
woke up because of a user-triggered event. The actual mechanism by
which this determination is made isn't
On Wed, May 6, 2015 at 1:38 AM, David Lang da...@lang.hm wrote:
On Wed, 6 May 2015, Rafael J. Wysocki wrote:
You are, of course, correct. Ultimately the only requirement we have
is that there exists a way for userspace to determine if the system
woke up because of a user-triggered event.
On Tuesday, May 05, 2015 01:58:12 PM Chirantan Ekbote wrote:
On Tue, May 5, 2015 at 12:35 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 5 May 2015, Chirantan Ekbote wrote:
This is our plan for the next version (see my email earlier in this
thread). Keeping a hybrid power state
On Mon, 4 May 2015, Chirantan Ekbote wrote:
Ok so now I can talk about how lucid sleep fits into all of this. The
power manager only considers a suspend attempt successful if the write
to /sys/power/state was successful. If the suspend was successful,
the power manager then reads another
On Tue, May 5, 2015 at 3:46 AM, Bastien Nocera had...@hadess.net wrote:
On Mon, 2015-05-04 at 16:30 -0700, Chirantan Ekbote wrote:
snip
In the interest of brevity, I didn't go into the design of suspend /
resume in userspace in my last email but it seems like there's no way
around it.
On Tue, 5 May 2015, Chirantan Ekbote wrote:
This is our plan for the next version (see my email earlier in this
thread). Keeping a hybrid power state with hacks in the drivers isn't
really maintainable, scalable, or upstream-able and has caused us some
headaches already. Unfortunately we
On 5 May 2015 at 00:19, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
On 30 April 2015 at 20:54, Chirantan Ekbote chiran...@chromium.org wrote:
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Apr 30,
On Tue, May 5, 2015 at 12:35 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 5 May 2015, Chirantan Ekbote wrote:
This is our plan for the next version (see my email earlier in this
thread). Keeping a hybrid power state with hacks in the drivers isn't
really maintainable, scalable, or
On Tue, May 5, 2015 at 7:39 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 4 May 2015, Chirantan Ekbote wrote:
Ok so now I can talk about how lucid sleep fits into all of this. The
power manager only considers a suspend attempt successful if the write
to /sys/power/state was
On Mon, 2015-05-04 at 16:30 -0700, Chirantan Ekbote wrote:
snip
In the interest of brevity, I didn't go into the design of suspend /
resume in userspace in my last email but it seems like there's no way
around it.
Ignoring lucid sleep for a moment, here is how a regular suspend
works
in
On Mon, May 4, 2015 at 3:12 PM, Rafael J. Wysocki wrote:
> On Thursday, April 30, 2015 11:54:51 AM Chirantan Ekbote wrote:
>> On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
>> > Hi,
>> >
>> > On Thu, Apr 30, 2015 at 10:10 AM, John Stultz
>> > wrote:
>> >> On Thu, Apr 30, 2015 at 9:25
On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
> On 30 April 2015 at 20:54, Chirantan Ekbote wrote:
> > On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
> >> Hi,
> >>
> >> On Thu, Apr 30, 2015 at 10:10 AM, John Stultz
> >> wrote:
> >>> On Thu, Apr 30, 2015 at 9:25 AM, Bastien
On Thursday, April 30, 2015 11:54:51 AM Chirantan Ekbote wrote:
> On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
> > Hi,
> >
> > On Thu, Apr 30, 2015 at 10:10 AM, John Stultz
> > wrote:
> >> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote:
> >>> On Tue, 2014-10-21 at 10:04
On Mon, May 4, 2015 at 3:12 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, April 30, 2015 11:54:51 AM Chirantan Ekbote wrote:
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org
On Thursday, April 30, 2015 11:54:51 AM Chirantan Ekbote wrote:
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org
wrote:
On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera had...@hadess.net
On Friday, May 01, 2015 11:02:19 AM Tomeu Vizoso wrote:
On 30 April 2015 at 20:54, Chirantan Ekbote chiran...@chromium.org wrote:
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org
wrote:
On
On 30 April 2015 at 20:54, Chirantan Ekbote wrote:
> On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
>> Hi,
>>
>> On Thu, Apr 30, 2015 at 10:10 AM, John Stultz wrote:
>>> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote:
On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On 30 April 2015 at 20:54, Chirantan Ekbote chiran...@chromium.org wrote:
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org wrote:
On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera had...@hadess.net
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote:
> Hi,
>
> On Thu, Apr 30, 2015 at 10:10 AM, John Stultz wrote:
>> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote:
>>> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz wrote:
> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote:
>> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
>>> On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera
>>> wrote:
>>> > Hey,
>>> >
>>> > GNOME has had discussions with kernel
On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote:
> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
>> On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera
>> wrote:
>> > Hey,
>> >
>> > GNOME has had discussions with kernel developers in the past, and,
>> > fortunately, in some cases we
On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
> On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera
> wrote:
> > Hey,
> >
> > GNOME has had discussions with kernel developers in the past, and,
> > fortunately, in some cases we were able to make headway.
> >
> > There are however a number
On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera had...@hadess.net wrote:
On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera had...@hadess.net
wrote:
Hey,
GNOME has had discussions with kernel developers in the past, and,
fortunately, in
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org wrote:
On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera had...@hadess.net wrote:
On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera had...@hadess.net
wrote:
Hey,
On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson o...@lixom.net wrote:
Hi,
On Thu, Apr 30, 2015 at 10:10 AM, John Stultz john.stu...@linaro.org wrote:
On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera had...@hadess.net wrote:
On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On Tue, Oct
On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera had...@hadess.net
wrote:
Hey,
GNOME has had discussions with kernel developers in the past, and,
fortunately, in some cases we were able to make headway.
There are however a
Hi!
On Mon 2014-10-27 15:19:39, Bastien Nocera wrote:
> > Now, I do think knowing which IRQ did bring you out of suspend is
> > useful, but mostly for power-debugging when you're trying to optimize
> > battery life. But for userland logic, I think its far too prone to
> > races.
>
> I also
Hi!
On Mon 2014-10-27 15:19:39, Bastien Nocera wrote:
Now, I do think knowing which IRQ did bring you out of suspend is
useful, but mostly for power-debugging when you're trying to optimize
battery life. But for userland logic, I think its far too prone to
races.
I also cannot know,
On Tue 04-11-14 20:55:15, Heinrich Schuchardt wrote:
> On 04.11.2014 10:28, Jan Kara wrote:
>
> >>If inotify_add_watch() would allow to mark a complete mount (like
> >>fanotify_mark() called with FAN_MOUNT) events for all files on this
> >>mount could be detected. If furthermore inotify_read()
On Tue 04-11-14 20:55:15, Heinrich Schuchardt wrote:
On 04.11.2014 10:28, Jan Kara wrote:
If inotify_add_watch() would allow to mark a complete mount (like
fanotify_mark() called with FAN_MOUNT) events for all files on this
mount could be detected. If furthermore inotify_read() would return
On 04.11.2014 10:28, Jan Kara wrote:
If inotify_add_watch() would allow to mark a complete mount (like
fanotify_mark() called with FAN_MOUNT) events for all files on this
mount could be detected. If furthermore inotify_read() would return
the complete relative path of the changed file relative
On Mon 03-11-14 19:21:43, Heinrich Schuchardt wrote:
> On 31.10.2014 10:36, Jan Kara wrote:
> >On Mon 27-10-14 20:02:51, Sergey "Shnatsel" Davidoff wrote:
> >>>If "recursive mtime" was available, would that work for you?
> >>
> >>It would work for detecting "offline" changes. I suppose recursive
>
On Mon 03-11-14 19:21:43, Heinrich Schuchardt wrote:
On 31.10.2014 10:36, Jan Kara wrote:
On Mon 27-10-14 20:02:51, Sergey Shnatsel Davidoff wrote:
If recursive mtime was available, would that work for you?
It would work for detecting offline changes. I suppose recursive
mtime not viable
On 04.11.2014 10:28, Jan Kara wrote:
If inotify_add_watch() would allow to mark a complete mount (like
fanotify_mark() called with FAN_MOUNT) events for all files on this
mount could be detected. If furthermore inotify_read() would return
the complete relative path of the changed file relative
On 31.10.2014 10:36, Jan Kara wrote:
On Mon 27-10-14 20:02:51, Sergey "Shnatsel" Davidoff wrote:
If "recursive mtime" was available, would that work for you?
It would work for detecting "offline" changes. I suppose recursive
mtime not viable for online monitoring, mostly because detecting
> > It's a reasonable ask but answers even if available are likely
> > to be things like "because GPE36" and GPE36 will just be some connection
> > to something that could be anything from a lid switch to a light sensor
> > or even a smart wifi chip deciding it wants the CPU to help out because
>
It's a reasonable ask but answers even if available are likely
to be things like because GPE36 and GPE36 will just be some connection
to something that could be anything from a lid switch to a light sensor
or even a smart wifi chip deciding it wants the CPU to help out because
you are
On 31.10.2014 10:36, Jan Kara wrote:
On Mon 27-10-14 20:02:51, Sergey Shnatsel Davidoff wrote:
If recursive mtime was available, would that work for you?
It would work for detecting offline changes. I suppose recursive
mtime not viable for online monitoring, mostly because detecting file
On Fri, Oct 31, 2014 at 6:54 AM, Bastien Nocera wrote:
> On Tue, 2014-10-28 at 07:36 -0700, John Stultz wrote:
>> On Tue, Oct 28, 2014 at 5:36 AM, Bastien Nocera wrote:
>> > Maybe the wake-up reason isn't good enough on its own, but how do I know
>> > which one the possible wake-up reasons was
On Thu, 2014-10-30 at 23:39 +, One Thousand Gnomes wrote:
> > > You'd have to solve it in the firmware.
> >
> > Not if the kernel can tell us that the event occurred and when.
>
> Which it can only do if the firmware told the kernel meaningfully !
>
> > And I think I have one of those
On Thu, 2014-10-30 at 23:25 +, One Thousand Gnomes wrote:
> O> The kernel receives an interrupt, likely on a different device. Again,
> > I'm talking about "legacy" devices, for which suspend is actually a
> > state. If the device is only in low-power mode, you'd probably get the
> > event on
On Thu, 2014-10-30 at 18:41 +0100, Pavel Machek wrote:
> On Thu 2014-10-30 16:15:15, Bastien Nocera wrote:
> > On Thu, 2014-10-30 at 11:05 -0400, Theodore Ts'o wrote:
> > > On Thu, Oct 30, 2014 at 03:45:02PM +0100, Bastien Nocera wrote:
> > > > > Actually Maemo people (on Nokia N900 and friends)
On Thu, 2014-10-30 at 19:23 +0100, Pavel Machek wrote:
> On Thu 2014-10-30 16:07:35, Bastien Nocera wrote:
> > On Thu, 2014-10-30 at 07:53 -0700, Andy Lutomirski wrote:
> > > On Thu, Oct 30, 2014 at 7:45 AM, Bastien Nocera wrote:
> > > > On Wed, 2014-10-29 at 22:16 +0100, Pavel Machek wrote:
> >
On Tue, 2014-10-28 at 07:36 -0700, John Stultz wrote:
> On Tue, Oct 28, 2014 at 5:36 AM, Bastien Nocera wrote:
> > Maybe the wake-up reason isn't good enough on its own, but how do I know
> > which one the possible wake-up reasons was the last one to trigger?
>
> So I feel like I'm still missing
On Mon 27-10-14 20:02:51, Sergey "Shnatsel" Davidoff wrote:
> > If "recursive mtime" was available, would that work for you?
>
> It would work for detecting "offline" changes. I suppose recursive
> mtime not viable for online monitoring, mostly because detecting file
> renaming would be a massive
On Mon 27-10-14 20:02:51, Sergey Shnatsel Davidoff wrote:
If recursive mtime was available, would that work for you?
It would work for detecting offline changes. I suppose recursive
mtime not viable for online monitoring, mostly because detecting file
renaming would be a massive PITA (and
On Tue, 2014-10-28 at 07:36 -0700, John Stultz wrote:
On Tue, Oct 28, 2014 at 5:36 AM, Bastien Nocera had...@hadess.net wrote:
Maybe the wake-up reason isn't good enough on its own, but how do I know
which one the possible wake-up reasons was the last one to trigger?
So I feel like I'm
On Thu, 2014-10-30 at 19:23 +0100, Pavel Machek wrote:
On Thu 2014-10-30 16:07:35, Bastien Nocera wrote:
On Thu, 2014-10-30 at 07:53 -0700, Andy Lutomirski wrote:
On Thu, Oct 30, 2014 at 7:45 AM, Bastien Nocera had...@hadess.net wrote:
On Wed, 2014-10-29 at 22:16 +0100, Pavel Machek
On Thu, 2014-10-30 at 18:41 +0100, Pavel Machek wrote:
On Thu 2014-10-30 16:15:15, Bastien Nocera wrote:
On Thu, 2014-10-30 at 11:05 -0400, Theodore Ts'o wrote:
On Thu, Oct 30, 2014 at 03:45:02PM +0100, Bastien Nocera wrote:
Actually Maemo people (on Nokia N900 and friends) got it
On Thu, 2014-10-30 at 23:25 +, One Thousand Gnomes wrote:
O The kernel receives an interrupt, likely on a different device. Again,
I'm talking about legacy devices, for which suspend is actually a
state. If the device is only in low-power mode, you'd probably get the
event on the input
On Thu, 2014-10-30 at 23:39 +, One Thousand Gnomes wrote:
You'd have to solve it in the firmware.
Not if the kernel can tell us that the event occurred and when.
Which it can only do if the firmware told the kernel meaningfully !
And I think I have one of those devices, an Intel
On Fri, Oct 31, 2014 at 6:54 AM, Bastien Nocera had...@hadess.net wrote:
On Tue, 2014-10-28 at 07:36 -0700, John Stultz wrote:
On Tue, Oct 28, 2014 at 5:36 AM, Bastien Nocera had...@hadess.net wrote:
Maybe the wake-up reason isn't good enough on its own, but how do I know
which one the
> > You'd have to solve it in the firmware.
>
> Not if the kernel can tell us that the event occurred and when.
Which it can only do if the firmware told the kernel meaningfully !
> And I think I have one of those devices, an Intel Baytrail tablet.
>
> > - Suspend/Resume on such machines are a
O> The kernel receives an interrupt, likely on a different device. Again,
> I'm talking about "legacy" devices, for which suspend is actually a
> state. If the device is only in low-power mode, you'd probably get the
> event on the input device, which is accessible from user-space.
I don't
> I wouldn't consider this "suspend to RAM", but that's because I expect
> the firmware to implement most of that. Anyway, that's splitting hair.
Quite the reverse in many cases. If your hardware has low power idle you
probably have almost no firmware involved (if any). It's the old world
model
> It matters because for laptops, what's important is whether the lid is
> closed or not. Whether and how the laptop was "woken" is really
> beside the point, as others have argued. Your counter argument is
> that tablets don't have lids. But tablets are going to be using
> schemes similar to
On Thu 2014-10-30 16:07:35, Bastien Nocera wrote:
> On Thu, 2014-10-30 at 07:53 -0700, Andy Lutomirski wrote:
> > On Thu, Oct 30, 2014 at 7:45 AM, Bastien Nocera wrote:
> > > On Wed, 2014-10-29 at 22:16 +0100, Pavel Machek wrote:
> > >> On Wed 2014-10-29 16:26:16, Theodore Ts'o wrote:
> > >> > On
On Thu 2014-10-30 16:15:15, Bastien Nocera wrote:
> On Thu, 2014-10-30 at 11:05 -0400, Theodore Ts'o wrote:
> > On Thu, Oct 30, 2014 at 03:45:02PM +0100, Bastien Nocera wrote:
> > > > Actually Maemo people (on Nokia N900 and friends) got it right: unlike
> > > > android devices, it does not
On Thu, 2014-10-30 at 11:34 -0400, Theodore Ts'o wrote:
> On Thu, Oct 30, 2014 at 04:15:15PM +0100, Bastien Nocera wrote:
> >
> > There are plenty of tablets around that aren't Android devices. There
> > are plenty of laptops that can be switched to a tablet mode for which
> > this wouldn't apply
On Thu, Oct 30, 2014 at 04:15:15PM +0100, Bastien Nocera wrote:
>
> There are plenty of tablets around that aren't Android devices. There
> are plenty of laptops that can be switched to a tablet mode for which
> this wouldn't apply either.
These "tablets" will either have enough battery that
On Thu, 2014-10-30 at 11:05 -0400, Theodore Ts'o wrote:
> On Thu, Oct 30, 2014 at 03:45:02PM +0100, Bastien Nocera wrote:
> > > Actually Maemo people (on Nokia N900 and friends) got it right: unlike
> > > android devices, it does not suspend to RAM at any point, and still
> > > has reasonable
On Thu, 2014-10-30 at 07:53 -0700, Andy Lutomirski wrote:
> On Thu, Oct 30, 2014 at 7:45 AM, Bastien Nocera wrote:
> > On Wed, 2014-10-29 at 22:16 +0100, Pavel Machek wrote:
> >> On Wed 2014-10-29 16:26:16, Theodore Ts'o wrote:
> >> > On Wed, Oct 29, 2014 at 12:19:56PM -0700, Andy Lutomirski
On Thu, Oct 30, 2014 at 03:45:02PM +0100, Bastien Nocera wrote:
> > Actually Maemo people (on Nokia N900 and friends) got it right: unlike
> > android devices, it does not suspend to RAM at any point, and still
> > has reasonable battery life.
>
> Android devices don't suspend to RAM. Neither do
On Thu, Oct 30, 2014 at 7:45 AM, Bastien Nocera wrote:
> On Wed, 2014-10-29 at 22:16 +0100, Pavel Machek wrote:
>> On Wed 2014-10-29 16:26:16, Theodore Ts'o wrote:
>> > On Wed, Oct 29, 2014 at 12:19:56PM -0700, Andy Lutomirski wrote:
>> > > For a tablet, isn't the relevant piece of information
On Wed, 2014-10-29 at 22:16 +0100, Pavel Machek wrote:
> On Wed 2014-10-29 16:26:16, Theodore Ts'o wrote:
> > On Wed, Oct 29, 2014 at 12:19:56PM -0700, Andy Lutomirski wrote:
> > > For a tablet, isn't the relevant piece of information whether the power
> > > button was recently pressed, not
On Wed, 2014-10-29 at 16:26 -0400, Theodore Ts'o wrote:
> On Wed, Oct 29, 2014 at 12:19:56PM -0700, Andy Lutomirski wrote:
> > For a tablet, isn't the relevant piece of information whether the power
> > button was recently pressed, not whether the power button caused the wakeup?
>
> For Android L
1 - 100 of 208 matches
Mail list logo
