Hi,
On 09/14/2018 06:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Sep 13, 2018 at 11:31:39AM -0400, Bastien Nocera wrote:
----- Original Message -----
On Thu, Sep 13, 2018 at 4:40 PM Bastien Nocera < bnocera@redhat.com > wrote:
It's broken. systemd will use it when GNOME isn't involved,
I don't think so:
$ grep -E '(HandlePower|HandleLid)' /etc/systemd/logind.conf #HandlePowerKey=poweroff #HandleLidSwitch=suspend #HandleLidSwitchExternalPower=suspend #HandleLidSwitchDocked=ignore
Systemd defaults to poweroff or suspend, not to suspend-then-hibernate. Only gnome now defaults to suspend-then-hibernate.
systemctl suspend-then-hibernate will make use of it, whether or not it's a default.
therefore, it will be broken at another level. It doesn't have a configuration on purpose, because it should just work. We don't add configuration options in GNOME when things should just work.
It doesn't just work, as explained by systemd and kernel folks. But it's an option you can use if you want (optionally, not default).
*should*. I know it doesn't work, otherwise we wouldn't be having that conversation, and I wouldn't be using a conditional :)
Disabling the support at the systemd level is as easy as masking a target. Somebody interested in using the feature just needs to unask a target, without needing to make changes to GNOME on top of that.
That means you have binary behavior, either or. That doesn't give people options to easily experiment on their existing hardware, or use the best approach at a given moment (i.e. suspend on monday to thursday, suspend-then-hibernate on friday).
It does, just mask and unmask the command. It doesn't require recompiling GNOME, and doesn't force GNOME to show options we know are broken, whether in Tweaks or Settings themselves.
This is what you want to do.
Adding a new configuration option doesn't explain to the end-user why this might be a bad option to enable in the current state. It doesn't explain why it's not enabled by default if it's a good feature to use.
As I suggested, it doesn't need to be exposed in GUI. This is clearly experimental stuff that needs to get stabilized over time (hopefully), and it's completely fine if only power users can find it. But if GNOME doesn't allow even power users to use it, then we can hardly hope for improving the kernel and distro support in the future. It's those power users that generate bug reports that generate fixes.
systemd has an option to disable it at runtime. What's the problem with using that instead of adding more moving parts to GNOME?
Hi,
[replying here, because I don't see a better point in the thread]
IMHO it is better to disable hibernation in systemd if we know it cannot work rather than disable s2h permanently in gnome. In particular, it is fairly easy to tweak systemd to understand the 'noresume' parameter and notice the lack of 'resume=' (Long term we want to make hibernation work without resume=, but until then.) I'll try to get this ready before F29 final.
That should solve the case of "configuration" issues, and will leave us only with those cases where the kernel drivers have issues.
Although it would be good to make sure that systemd does not advertise hibernate or hybrid support when there are configuration issues, that is not enough.
There will be many driver issues and we simply cannot have F29 using hibernate by default anywhere.
So if systemd is going to keep advertising support on systems where the config is ok for it, then we need to patch GNOME to not use it (by default).
Would it be possible to stop systemd from having hibernate support completely, with some (simple) way for users who want to use hhibernate to disable this behavior by changing the config ?
Note I'm not saying that that is the best solution, I just wonder if it is doable and what your take is on solving this that way ?
Regards,
Hans