Messages in this thread |  | | Subject | Re: A desktop environment[1] kernel wishlist | From | Bastien Nocera <> | Date | Fri, 31 Oct 2014 15:01:29 +0100 |
| |
On Thu, 2014-10-30 at 23:25 +0000, 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 device, which is accessible from user-space. > > I don't believe so - the firmware ate it. > > > Knowing why the Wi-Fi card woke up is also important when there isn't a > > full "suspend" state. As was mentioned, it's useful for power debugging, > > but it's also useful because that tells things outside the network card > > driver what happened. > > Wifi devices that are smart generally have a fair bit of info they > provide themselves on this. In particular if you are using a deep idle > type behaviour they may well wake every minute or so just to poke a > packet out to keep any NAT mapping alive. > > > As I mentioned in more recent emails on this thread, maybe we don't want > > to know what woke the system up, but knowing that a wake-up event > > occurred on this device, at this time, would allow us to make the > > software act accordingly. The fact that we don't know that means that we > > cannot take appropriate action. > > What woke the system up may also not be a singular item. Suppose the > alarm goes off as the user opens the lid and the wireless gets a wakeup > packet in the same window ?
Then each one of those devices would have their own wakeup reason set, with a timestamp.
|  |