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@xxxxxxxxxx > 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
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
