In Ubuntu, we got a bug filed about how suspends initiated outside of gnome-power-manager were not locking the screen correctly.
This is because it handled locking as a result of internal methods, not as a response to the Sleeping signal from upower. Ideally it would do that instead, but first, that signal needs to have enough information for a policy agent like gnome-power-manager to determine policy.
Which means it needs to tell listeners whether the sleep is a suspend or hibernate.
We received a patch for this by Phillip Susi (attached). It simply adds an int argument to the signal. Will existing dbus listeners be confused by the addition of a new argument?
Created attachment 45048
Adds signal arg
In Ubuntu, we got a bug filed about how suspends initiated outside of gnome-power-manager were not locking the screen correctly.
This is because it handled locking as a result of internal methods, not as a response to the Sleeping signal from upower. Ideally it would do that instead, but first, that signal needs to have enough information for a policy agent like gnome-power-manager to determine policy.
Which means it needs to tell listeners whether the sleep is a suspend or hibernate.
We received a patch for this by Phillip Susi (attached). It simply adds an int argument to the signal. Will existing dbus listeners be confused by the addition of a new argument?