Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 758848 - Add support for wake_notification and sleep_notification on Linux
: Add support for wake_notification and sleep_notification on Linux
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: unspecified
: All Linux
: -- normal with 5 votes (vote)
: ---
Assigned To: Philipp Kewisch [:Fallen]
Depends on:
Blocks: Instantbird 731390 682109 757762
  Show dependency treegraph
Reported: 2012-05-25 23:24 PDT by Philipp Kewisch [:Fallen]
Modified: 2014-04-01 11:51 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Philipp Kewisch [:Fallen] 2012-05-25 23:24:29 PDT
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?
Comment 1 Peter Weilbacher 2012-05-26 04:02:18 PDT
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;
   interface=org.freedesktop.UPower; member=Sleeping
signal sender=:1.9 -> dest=(null destination) serial=27930 path=/org/freedesktop/UPower;
   interface=org.freedesktop.UPower; member=NotifySleep
   string "suspend"

and then

signal sender=:1.9 -> dest=(null destination) serial=27931 path=/org/freedesktop/UPower;
   interface=org.freedesktop.UPower; member=Resuming
signal sender=:1.9 -> dest=(null destination) serial=27932 path=/org/freedesktop/UPower;
   interface=org.freedesktop.UPower; member=NotifyResume
   string "suspend"

On an older system there will be an equivalent with HAL.

Maybe this would be an alternative over using more direct kernel access.
Comment 2 Philipp Kewisch [:Fallen] 2012-05-27 04:30:48 PDT
Look what I found:
Comment 3 Karl Tomlinson (:karlt) 2012-05-27 18:03:59 PDT
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
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.
Comment 4 Mounir Lamouri (:mounir) 2012-05-29 02:52:15 PDT
Note that if this call is using hal, we might need/want to move the equivalent windows/mac calls to hal too.
Comment 5 Peter Weilbacher 2012-11-30 01:02:40 PST
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... <> 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...
Comment 6 Peter Weilbacher 2013-01-09 00:42:55 PST
So, it turns out that UPower support for these suspend-related notifications is very unstable ( In fact, the plan is to remove them from UPower before v1.0 ( 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.
Comment 7 Mounir Lamouri (:mounir) 2013-01-09 04:35:57 PST
Can't we use ACPI events?
Comment 8 Karl Tomlinson (:karlt) 2013-01-09 13:38:10 PST
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.
Comment 9 Philipp Kewisch [:Fallen] 2013-01-10 01:54:08 PST
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.

Note You need to log in before you can comment on or make changes to this bug.