On Fri, Jul 24, 2009 at 6:39 AM, Henrique de Moraes Holschuh<hmh@xxxxxxxxxx> wrote: > On Fri, 24 Jul 2009, ykzhao wrote: >> > > Well, we *already* deliver "lid opened" when the lid is opened, regardless >> > > of it waking up the computer or not. But we are missing a way to deliver >> > > other classes of wakeup events. >> > > >> > > I know of at least these (incomplete list): >> > > >> > > 1. network-initiated wakeup >> > > a. wired >> > > b. wireless >> > > c. long-range wireless >> > > >> > > 2. platform health/condition alarms >> > > a. battery alarm (two levels, warning and emergency) >> > > b. thermal alarm (two levels, warning and emergency) >> > > (we need these as generic alarms, not just reason-for-wakeup) >> > > >> > > 3. device (or device tree) hotplug/hotunplug >> > > a. hotunplug request or notification >> > > (we deliver the request/notification, but we don't know we should >> > > go back to sleep, so all we are missing is the reason-for-wakeup >> > > event) >> > > >> > > 4. management >> > > a. wake-up/power on clock >> > > b. remote management command (IMPI, etc) >> > > c. intrusion alarm >> > > d. theft alarm >> > > >> > > None of those have a standard interface to notify userspace of the reason of >> > > the wake up AFAIK. Many of these want a generic event interface to be >> > > delivered not just as reason-for-wakeup, but also as runtime events. >> > > >> > > And I guess we should also tell userspace what state we are waking up from >> > > (S5 clean state, S5/S4 hibernation, S3), sometimes it matters. >> > >> > Agreed, and same for the above. >> > >> > So, what in your opinion would be the best way to expose this information? > > Frankly? It needs to be an easy-to-extend ABI, and the only one that cames > to mind right now are uevents. That sounds like a great idea. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
