I recently found that wake_notification is only supported on Mac and Windows. I'd like to add support for this on Linux too, mainly to fix a calendar bug.
To do so it looks like I will need to call register_pm_notifier() which is from <linux/suspend.h>. It also looks like this header is not usually included in /usr/include, but it can be found in all 2.6 and 3.0 kernel headers. This is not supported in linux 2.4, where I could work around with CPU hotplug events. Is it required to support linux 2.4 also?
I have added code to widget/gtk2/nsToolkit.cpp that adds this notification. Is this the correct place to do so, or is there a more generic location for all linux variants?
I would appreciate if someone could tell me what the procedure is for including kernel headers like <linux/suspend.h>. Is it possible? Should I just forward define the functions and structs myself?
Since D-Bus is already a requirement, one could monitor such events with it. On a modern Linux system they appear in the /org/freedesktop/UPower path. On a suspend/wakeup cycle I see
signal sender=:1.9 -> dest=(null destination) serial=27929 path=/org/freedesktop/UPower;
signal sender=:1.9 -> dest=(null destination) serial=27930 path=/org/freedesktop/UPower;
signal sender=:1.9 -> dest=(null destination) serial=27931 path=/org/freedesktop/UPower;
signal sender=:1.9 -> dest=(null destination) serial=27932 path=/org/freedesktop/UPower;
On an older system there will be an equivalent with HAL.
Maybe this would be an alternative over using more direct kernel access.
Look what I found:
Yes, register_pm_notifier looks like a kernel function. I don't know if that is accessible from user space.
UPower vis D-Bus sounds like the modern way for apps to get these notifications.
No need to support older systems and further than gracefully failing to send the notifications.
This sounds like something that would sensibly go into Mozilla's "hal" via extension of hal/linux/UPowerClient.cpp.
A difficulty there is that code in that subdirectory should not use XPCOM, so there would have to be some code elsewhere to send the notification, but that could use (Mozilla's) hal. nsToolkit is where the cocoa port sends these notifications so nsToolkit might be a sensible place for the gtk port.
Another thing to be aware of is that the synchronous (blocking) calls in hal/linux/UPowerClient.cpp are tolerated only because that code is not used (or at least not frequently used) on desktop products.
If the D-Bus code is run on startup, then it would need to use only async calls.
It may be easier to use http://mxr.mozilla.org/mozilla-central/ident?i=nsDBusService
which is set up for async usage, but may still need extension. See nsNetworkManagerListener for existing usage.
If it is possible to only send the notification when there are clients listening, and the clients don't register during startup, then sync D-Bus through hal would probably be fine.
Note that if this call is using hal, we might need/want to move the equivalent windows/mac calls to hal too.
I looked at UPower again for a bit yesterday, and put together a small test program to do what would be needed here (outside Mozilla code). The problem is that I didn't get the signals I listed in comment 1 any more, neither with my test program nor with dbus-monitor or upower -m.
The signals related to sleep/hibernation don't show up any more, although I am testing this on the same system... <http://lists.freedesktop.org/archives/devkit-devel/2012-July/001304.html> tells me that apparently I am not the only one. I sent an email to that list, maybe there will be a reply this time...
So, it turns out that UPower support for these suspend-related notifications is very unstable (http://lists.freedesktop.org/archives/devkit-devel/2012-December/001330.html). In fact, the plan is to remove them from UPower before v1.0 (http://lists.freedesktop.org/archives/devkit-devel/2013-January/001339.html) and (re-)implement them in some other library.
To me this seems to suggest that this should be wontfix'ed since there is no interface available on Linux (let alone across Unixes) that could be used.
Can't we use ACPI events?
My /var/log/acpid includes events for various buttons, but I don't see and events for the actual sleep and wake, which could result from any or no button.
Instead of just WONTFIXing this bug, I'd suggest finding another way to implement this. If those folks would rather implement the signals in logind, then we should hook into logind. Maybe dbus will then also provide support for those signals, and we can again just use the dbus signal.
Implementing this bug is still a valid request, regardless of what method is used to fulfill it.