Messages in this thread |  | | Date | Thu, 30 Oct 2014 23:25:26 +0000 | From | One Thousand Gnomes <> | Subject | Re: A desktop environment[1] kernel wishlist |
| |
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 ?
Alan
|  |