Re: Disable (or make configurable and default to off) suspend-then-hibernate behavior in GNOME-3.30

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




----- Original Message -----
> Hi,
> 
> On Thu, Sep 13, 2018 at 1:21 PM, Matthias Clasen <mclasen@xxxxxxxxxx> wrote:
> > On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote:
> >> The thing is, hibernate does work for some users. And eventually will
> >> be made to work with secure boot as well. But it is very difficult for
> >> us to "support" a feature when the fixes are often blacklist x driver
> >> or edit your DSDT table.  There is a large variety of hardware and
> >> some of it just doesn't work.
> >>
> >
> > Well, everything worked for somebody at some point. But the answer can't
> > be to just add another toggle to the control-center so people can
> > experimentally
> > find out if it works for them at this time, choose-your-own-adventure
> > style.
> >
> > Either we commit to supporting it. Then we need to invest the time to make
> > it actually work. At the minimum, we need to be able to detect reliably
> > when
> > it will not work, so we can turn it off.
> >
> > Or we don't. In which case we should just remove it.
> Right, the kernel should stop advertising "disk" in /sys/power/state unless
> it
> can reliably hibernate.  If users want to opt-in to some hibernate
> tech-preview,
> they should have to add something to the kernel command line or so, imo.
> 
> The kernel shouldn't be exposing features it can't reliably provide.
> Again, as I understand it, it's not even a hardware-supported situation, it
> can
> potentially fail on *any system* if the swap partition is filled up
> the wrong way,
> if i'm not mistaken.

There's multiple levels of "support". The kernel doesn't know if it has enough
swap, this is checked by user-space, systemd in this case. Any additional
checks we'd want to make would probably be implemented in systemd, so
it can answer "CanHibernate" with a better degree of certainty.

> until, at least that is fixed, we really should stop exposing the
> feature without
> some sort of kernel command line opt-in situation.

I think that the kernel doesn't have enough information about the system
to be able to make the decision in a lot of cases, or it would cross subsystem
boundaries. For example, knowing if Secure Boot is enabled, whether there's
data encryption enabled, whether grub is correctly setup.

Having more checks in systemd might help. As for when the hardware drivers need
fixing, well, it's the same situation as for any other driver bug would be, and
hopefully fixed.
_______________________________________________
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




[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux