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(a)redhat.com >
>>> 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
>> 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.
>>> 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
>> 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
>>> 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
>> 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?
[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
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 ?