Arch Linux

heliumtt

Member

Registered: 2016-12-27

Posts: 27

[SOLVED] KDE power control underlying commands

Hello,

After digging I could not find anything on that anywhere.
When one trigges suspend, reboot etc from KDE, it sends a command via dbus.

However, where is the low level command finally triggered defined ?
In other words, which config file states that when PowerManagement issues hibernate, it does "systemctl hibernate" for example ?

 grep -ri "systemctl hibernate"  /usr 

returned nothing useful.

Is this hard-coded ?!

Thanks in advance !
Bye

Last edited by heliumtt (2016-12-29 00:08:33)

ks3

Member

Registered: 2016-07-07

Posts: 5

Re: [SOLVED] KDE power control underlying commands

It looks like KDE is sending a D-Bus message to UPower, and UPower in turn sends a D-Bus message directly to systemd-logind.  So there isn't really a "command" in the sense of a shell command, it is handled by sending a message directly into systemd.

heliumtt

Member

Registered: 2016-12-27

Posts: 27

Re: [SOLVED] KDE power control underlying commands

Thanks a lot. That is what I was wondering.
I had seen many posts about the dbus call but thought that perhaps something would convert it in a shell

command before logind.

Is this how the magic takes place (sorry, not that experienced in non basic-basic C):
- backend has the critical action string internally,
- it is copied in "method" g-string,
- g_dbus_proxy_call is what routes the call of "method" g-string to the backend logind (as set in the pre-processor variables show below ) ?

All that resulting in the fact that logind triggers the systemd target internally (equivalent to a "systemctl [suspend, reboot, hibernate]" ?

Thus to modify the result of KDE acpi action, modifying the systemd target/service is the thing to do ?

With that it would go to SOLVED I guess.
Thanks again !
Bye

#define LOGIND_DBUS_NAME                       "org.freedesktop.login1"
#define LOGIND_DBUS_PATH                       "/org/freedesktop/login1"
#define LOGIND_DBUS_INTERFACE                  "org.freedesktop.login1.Manager"

/**
 * up_backend_take_action:
 * @backend: The %UpBackend class instance
 *
 * Act upon the %UP_DEVICE_LEVEL_ACTION warning-level.
 **/
void
up_backend_take_action (UpBackend *backend)
{
	const char *method;

	method = up_backend_get_critical_action (backend);
	g_assert (method != NULL);

	/* Take action */
	g_debug ("About to call logind method %s", method);
	g_dbus_proxy_call (backend->priv->logind_proxy,
			   method,
			   g_variant_new ("(b)", FALSE),
			   G_DBUS_CALL_FLAGS_NONE,
			   G_MAXINT,
			   NULL,
			   NULL,
			   NULL);
}

Raynman

Member

Registered: 2011-10-22

Posts: 1,539

Re: [SOLVED] KDE power control underlying commands

Thanks a lot. That is what I was wondering.
I had seen many posts about the dbus call but thought that perhaps something would convert it in a shell command before logind.

Actually the commands like `systemctl hibernate` also call logind's D-Bus methods.

Thus to modify the result of KDE acpi action, modifying the systemd target/service is the thing to do ?

Maybe, maybe not. KDE and/or UPower may also allow you to configure some things. I don't use KDE/UPower, so I can't help you and because you made this thread about something else (see http://xyproblem.info/), maybe the people who would be able to help don't see this thread (and if they find it now, it's still not very clear what your end goal is).

heliumtt

Member

Registered: 2016-12-27

Posts: 27

Re: [SOLVED] KDE power control underlying commands

Thanks for the clarification.

Yes, sorry I did not clarify that and asked it more as a 'culture' question.
I am actually running Arch with KDE.

I am trying to replace suspend by hybrid-suspend. And trying to see where to tie-in since KDE does not provide the option in the drop down list.
So I thought I could just:
- leave suspend or hibernate in KDE,
- redirect the hibernate or suspend to hybrid.

Hope this clarifies,
Thanks in advance.

Raynman

Member

Registered: 2011-10-22

Posts: 1,539

Re: [SOLVED] KDE power control underlying commands

- redirect the hibernate or suspend to hybrid.

Well, if you look at

$ man systemd-sleep.conf

you can control what systemd tells the kernel when it is told (by KDE in your case) to suspend or hibernate. Based on [1]

If you would like to write hibernation image to swap and then suspend
to RAM (provided your platform supports it), you can try

echo suspend > /sys/power/disk; echo disk > /sys/power/state

you could try

[Sleep]
HibernateMode=suspend
HibernateState=disk

to turn hibernate into hybrid sleep. If that works, it may help you until the KDE folks finally decide how to add this option. [2]

[1] https://www.kernel.org/doc/Documentatio … swsusp.txt
[2] https://bugs.kde.org/show_bug.cgi?id=358957

heliumtt

Member

Registered: 2016-12-27

Posts: 27

Re: [SOLVED] KDE power control underlying commands

Hello, thanks !
It does exactly what was needed.

Yes, I had seen the kde bug and that is why I was looking for a workaround.

However, not as good as if the 3 different modes were listed in KDE: I would need to use the 3 different sleep modes to define a different behavious in several cases.

Hopefully it will be soon implemented.

Thanks again.

Xexanos

Member

Registered: 2017-05-27

Posts: 1

Re: [SOLVED] KDE power control underlying commands

I know this Thread has not been touched for a while, but since it seem to be the answer to my problem I'll just ask here:
Why should I use

[Sleep]
HibernateMode=suspend
HibernateState=disk

instead of

[Sleep]
HibernateMode=hybrid-sleep
HibernateState=hybrid-sleep

I already tested it and the 2nd Version does not work. I'm just wondering, why that is the case.