On Thu, Sep 13, 2018 at 11:21 AM, 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. 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 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. 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. -- Chris Murphy _______________________________________________ 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
