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
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, bu
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 only
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
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 irrelev
> 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 occu
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 w
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 /sys/power/
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 a
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 someth
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 t
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 and
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 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 luc
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 suspe
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 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:
> >> >> H
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 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 A
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 No
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 -0700,
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 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
wr
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 wer
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 of
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
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() wou
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 t
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 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
> > 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
> >
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 th
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 device
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 t
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) go
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
> > 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 believe
> 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 of
> 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 An
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 suspend
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 they
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 batte
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 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 battery life.
>
> Android devices don't suspend to RAM. Neither do T
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 whe
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 whether
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
On Tue, 2014-10-28 at 22:57 +, One Thousand Gnomes wrote:
> > If the firmware eats that button (which I hope it wouldn't, but I
> > probably should know better then to expect sane behavior), how does
> > the kernel know anything more?
>
> The firmware is generally going to do whatever it belie
On Mon, 2014-10-27 at 09:56 -0700, John Stultz wrote:
> On Mon, Oct 27, 2014 at 7:19 AM, Bastien Nocera wrote:
> > I also cannot know, from user-space, whether Wake-On-LAN,
> > Wake-On-Wireless-LAN, or the Wi-Fi card's "network proximity" triggered
> > coming out of suspend for example.
> >
> > I
On Tue, 2014-10-28 at 19:50 +0100, Pavel Machek wrote:
> Hi!
>
> > > > > For mobile
> > > > > devices this is an expected design point, but for off-the-shelf
> > > > > laptops with big fans and exhaust vents, I'm not sure how safe this
> > > > > would be, so you may need to constrain this functi
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 whether the power button caused the wakeup?
>
> For Android L devices
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 devices, it has been reported that the device might
power up its s
On 10/27/2014 07:31 AM, Bastien Nocera wrote:
> On Mon, 2014-10-27 at 10:28 +0100, Pavel Machek wrote:
>> Hi!
>>
I suspect wakeup type reporting is maybe not the best way to go about
this, since there may be a number of causes for wakeups and they can
arrive closely together in diffe
> If the firmware eats that button (which I hope it wouldn't, but I
> probably should know better then to expect sane behavior), how does
> the kernel know anything more?
The firmware is generally going to do whatever it believes is "correct",
which may nor may not be determined by what the hardwa
> I believe you should really use "is lid opened or AC or dock
> connected" to determine if it was automatic resume or not. It should
> work better and you can actually do it today.
There is no useful LID information on anything else either.
Alan
--
To unsubscribe from this list: send the line "u
Hi!
> > > > For mobile
> > > > devices this is an expected design point, but for off-the-shelf
> > > > laptops with big fans and exhaust vents, I'm not sure how safe this
> > > > would be, so you may need to constrain this functionality somehow (or
> > > > look to see if a enforced low-power res
-- Forwarded message --
From: Rogelio Serrano
Date: Tue, Oct 28, 2014 at 4:40 PM
Subject: Re: A desktop environment[1] kernel wishlist
To: Bastien Nocera
On Tue, Oct 28, 2014 at 12:36 PM, Bastien Nocera wrote:
>
> How do I detect that the screen is visible on a tab
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 why its so critical to know what the
last-event was? To me it s
On Mon, 2014-10-27 at 16:59 -0400, Zygo Blaxell wrote:
> On Mon, Oct 27, 2014 at 03:28:04PM +0100, Bastien Nocera wrote:
> > On Wed, 2014-10-22 at 13:04 -0400, Zygo Blaxell wrote:
> > > On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote:
> > > > On Tue, 2014-10-21 at 11:00 -0700, John S
On Mon, Oct 27, 2014 at 03:28:04PM +0100, Bastien Nocera wrote:
> On Wed, 2014-10-22 at 13:04 -0400, Zygo Blaxell wrote:
> > On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote:
> > > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> > > > On Tue, Oct 21, 2014 at 10:14 AM, Bastien
On Mon, Oct 27, 2014 at 7:19 AM, Bastien Nocera wrote:
> I also cannot know, from user-space, whether Wake-On-LAN,
> Wake-On-Wireless-LAN, or the Wi-Fi card's "network proximity" triggered
> coming out of suspend for example.
>
> I can certainly check for the status of the lid, but I wouldn't know
On Mon, Oct 27, 2014 at 05:09:06PM +0100, Bastien Nocera wrote:
> > > By having a well-known protocol and defined semantics on top of that
> > > communication channel. I could try and re-explain why kdbus is needed,
> > > but I wouldn't do as good a job as the people working on it, so best to
> >
> When I read your wish, I guess adding the capability to watch mounts with
> inotify would satisfy your needs. Would you agree?
The problem with inotify is that it's very inefficient for monitoring
hundreds of thousands of files, which is a fairly common case on the
desktop. I cannot see how supp
On Mon, Oct 27, 2014 at 8:45 AM, Bastien Nocera wrote:
> On Mon, 2014-10-27 at 08:12 -0700, Andy Lutomirski wrote:
>> On Oct 27, 2014 6:56 AM, "Bastien Nocera" wrote:
>> >
>> > On Tue, 2014-10-21 at 12:28 -0700, Andy Lutomirski wrote:
>> > > On 10/21/2014 01:49 AM, Bastien Nocera wrote:
>> > > >
On Mon, 2014-10-27 at 09:08 -0700, Andy Lutomirski wrote:
> On Mon, Oct 27, 2014 at 8:45 AM, Bastien Nocera wrote:
> > On Mon, 2014-10-27 at 08:12 -0700, Andy Lutomirski wrote:
> >> On Oct 27, 2014 6:56 AM, "Bastien Nocera" wrote:
> >> >
> >> > On Tue, 2014-10-21 at 12:28 -0700, Andy Lutomirski w
> 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 we already have fanotify with
exactly this problem).
Anothe
On Mon, 2014-10-27 at 16:31 +0100, Geert Uytterhoeven wrote:
> Hi Bastien,
>
> On Mon, Oct 27, 2014 at 3:20 PM, Bastien Nocera wrote:
> > On Tue, 2014-10-21 at 20:24 +0200, Geert Uytterhoeven wrote:
> >> On Tue, Oct 21, 2014 at 7:14 PM, Bastien Nocera wrote:
> >> >> As for: 'Export of "wake reas
On Mon, 2014-10-27 at 08:12 -0700, Andy Lutomirski wrote:
> On Oct 27, 2014 6:56 AM, "Bastien Nocera" wrote:
> >
> > On Tue, 2014-10-21 at 12:28 -0700, Andy Lutomirski wrote:
> > > On 10/21/2014 01:49 AM, Bastien Nocera wrote:
> > > > Hey,
> > > >
> > > > GNOME has had discussions with kernel deve
Hi Bastien,
On Mon, Oct 27, 2014 at 3:20 PM, Bastien Nocera wrote:
> On Tue, 2014-10-21 at 20:24 +0200, Geert Uytterhoeven wrote:
>> On Tue, Oct 21, 2014 at 7:14 PM, Bastien Nocera wrote:
>> >> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
>> >> lid open, etc.) and wakeal
On Oct 27, 2014 6:56 AM, "Bastien Nocera" wrote:
>
> On Tue, 2014-10-21 at 12:28 -0700, Andy Lutomirski wrote:
> > On 10/21/2014 01:49 AM, Bastien Nocera wrote:
> > > Hey,
> > >
> > > GNOME has had discussions with kernel developers in the past, and,
> > > fortunately, in some cases we were able t
On Mon, 2014-10-27 at 10:28 +0100, Pavel Machek wrote:
> Hi!
>
> > > I suspect wakeup type reporting is maybe not the best way to go about
> > > this, since there may be a number of causes for wakeups and they can
> > > arrive closely together in different orders, which can result in
> > > races.
On Wed, 2014-10-22 at 13:04 -0400, Zygo Blaxell wrote:
> On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote:
> > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> > > On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera
> > > wrote:
> > > >> As for: 'Export of "wake reason" when the
On Tue, 2014-10-21 at 20:24 +0200, Geert Uytterhoeven wrote:
> On Tue, Oct 21, 2014 at 7:14 PM, Bastien Nocera wrote:
> >> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
> >> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm)
> >> documentation'
> >>
> >> Can you e
On Tue, 2014-10-21 at 12:10 -0700, John Stultz wrote:
> On Tue, Oct 21, 2014 at 11:09 AM, Bastien Nocera wrote:
> > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> >> I suspect wakeup type reporting is maybe not the best way to go about
> >> this, since there may be a number of causes for
On Tue, 2014-10-21 at 12:28 -0700, Andy Lutomirski wrote:
> On 10/21/2014 01: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 of items th
Hi!
> > I suspect wakeup type reporting is maybe not the best way to go about
> > this, since there may be a number of causes for wakeups and they can
> > arrive closely together in different orders, which can result in
> > races.
> >
> > For instance, if the machine suspends, and sets an alarm t
On Tue 2014-10-21 13:11:07, Sergey wrote:
> Hey everyone,
>
> I'm glad we're having some discussion on this, because we have almost
> exactly the same kernel wishlist internally for elementary OS / Pantheon DE.
>
> I believe I can further elaborate on the VFS monitoring part. We need a file
> mon
On 21.10.2014 15:11, Sergey wrote:
Hey everyone,
I'm glad we're having some discussion on this, because we have almost
exactly the same kernel wishlist internally for elementary OS / Pantheon DE.
I believe I can further elaborate on the VFS monitoring part. We need a file
monitoring facility th
On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote:
> On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> > On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera wrote:
> > >> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
> > >> lid open, etc.) and wakealarm (/sy
On Tue, Oct 21, 2014 at 9:11 AM, Sergey wrote:
> Hey everyone,
>
> I'm glad we're having some discussion on this, because we have almost
> exactly the same kernel wishlist internally for elementary OS / Pantheon DE.
>
> I believe I can further elaborate on the VFS monitoring part. We need a file
>
Hello,
About zram, pre-3.10 is really old. At that time, there were some trouble
in zram but I belive most of known bugs should fix since 3.14 merged
from staging and enhanced much so I suggest you try it with recent zram.
If you find a problem, let me know it.
Thanks.
On Tue, Oct 21, 2014 at 01
On Tue, Oct 21, 2014 at 12:43 PM, Al Viro wrote:
> On Tue, Oct 21, 2014 at 12:28:12PM -0700, Andy Lutomirski wrote:
>
>> Why is kdbus needed?
>
> Presumably because freedesktop crowd has made an architectural mistake and
> pushed dbus as solution to all problems. And ran into limitations of
> tha
On Tue, Oct 21, 2014 at 12:28:12PM -0700, Andy Lutomirski wrote:
> Why is kdbus needed?
Presumably because freedesktop crowd has made an architectural mistake and
pushed dbus as solution to all problems. And ran into limitations of
that, er, solution. Then, instead of perhaps reconsidering the
On 10/21/2014 01: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 of items that we still don't have solutions
> for, items that kernel developers mig
On 10/21/2014 11:09 AM, Bastien Nocera wrote:
> On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
>> On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera wrote:
>>> Hey,
>>>
>>> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera wrote:
>
On Tue, Oct 21, 2014 at 11:09 AM, Bastien Nocera wrote:
> On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
>> I suspect wakeup type reporting is maybe not the best way to go about
>> this, since there may be a number of causes for wakeups and they can
>> arrive closely together in different o
On Tue, Oct 21, 2014 at 7:14 PM, Bastien Nocera wrote:
>> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
>> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm)
>> documentation'
>>
>> Can you expand more on the rational for the need here? Is this for UI
>> for power
On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera wrote:
> > Hey,
> >
> > 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 wi
On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera wrote:
> Hey,
>
> 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
Hey,
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 o
1 - 100 of 104 matches
Mail list logo
