On Thu, Sep 13, 2018 at 11:21 AM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Thu, Sep 13, 2018 at 1:10 PM Justin Forbes <jmforbes(a)linuxtx.org> 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
find out if it works for them at this time, choose-your-own-adventure style.
I agree it shouldn't be generally available, as it's in effect experimental.
Either we commit to supporting it. Then we need to invest the time to
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.
It's possibly not even a question for a kernel developer specializing
in power management issues can answer.
e.g. one of my newer laptops, an HP Spectre, suspends to RAM (S3) just
fine in Windows; but then it stopped working due to a Linux kernel
update. After bisecting that, they said the changes could not possibly
be related, and after a lot of ACPI debugging they gave up and said it
must be a firmware bug contact the vendor, who basically say well it
works on Windows. In the meantime, I'm able to suspect with
[chris@f29h ~]$ cat /etc/tmpfiles.d/suspendfix.conf
## Fix suspend bug
w /proc/acpi/wakeup - - - - PWRB
How could that requirement be detected reliably? I think it's unlikely
that Microsoft is working around these problems on a case by case
basis. It seems more likely the hardware vendors are tweaking their
firmware to make certain it works with the Windows implementation.
Apple on the other hand could be doing it either way.