On Mon, Feb 10, 2020 at 4:12 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > Continued from the 'background and summary' email: > https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx/message/V5MOCX23KU45J3WXUN6TCGEJYQLXQYUL/ > > Adding Hans and Matthew and Lennart to cc. > > Questions I have are: > > - WG is considering dropping creation of swap partitions by default, > in favor of swap-on-ZRAM. Any concerns? (We do know it's not possible > to use a ZRAM device for hibernation, but the kernel will look to > another swap device for contiguous free space to write out a > hibernation image.) > > - What's the status of s2idle in the kernel? > > - What sort of work is needed outside the kernel to properly support > s2idle, or is this predominantly kernel work? Microsoft documents on > Modern Standby suggest minimal application effort. [1] A lot of the functionality is implemented in a non standard extension to ACPI called PEP: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-peps-for-acpi-services > - Prospect of kernel support to separate swap and hibernation > partitions (and/or swap files)? Or systemd method of creating then > activating swapfiles on demand? > > - Prospect of hibernation supported with UEFI Secure Boot? > > - Is hibernation a better fallback than poweroff, given the > significant reliability differential? Why? Poweroff is universal, > hibernation isn't. What's the argument that a non-universally > available fallback is better than the universal fallback? > > - What are the implications of hibernation if Fedora will move to > measured boot? (I'm not sure how mainstream that function is expected > to be, or it's use case specific opt-in.) There's still a lot of work to be done there, but at least for IoT we're looking at least being able to opt-in to this soon, I suspect it will be quite a bit more work for something like workstation. > - There's some anecdotal evidence users are disabling UEFI Secure > Boot, possibly quite a lot [2]. Does there need to be an effort at > making the signing of user built kernel and module easier? Can it be > made easier? I don't know custom or out of tree modules is a > significant motive for disabling SB, vs other explanations. I don't think we have a break down between distros there, a lot of distros such as Debian didn't support it until very recently, distros like Gentoo and Arch still don't and so there's a lot of docs in those communities where the first instruction is to disable it. > - A systemd TODO makes me wonder: Does anyone have (corroborating) > data on the reliability of firmware or battery reporting, when the > system, and thus the battery, are under significant load? [3] I've > discussed with a reliable source that on 2+ year old hardware, the > vast majority of batteries are effectively broken and aren't likely to > report anything reliably if they are under significant load, in > particular waking from S3. By anything, I mean, time remaining, power > remaining, and current power consumption rate. Would s2idle instead of > S3 would make this more reliable? > > - It doesn't sound like S1 is really used at all, even though kernel > docs say it's supported as shallow/standby. (?) Is it more or less > reliable than S3? > > - I'm inclined to think we should mimic what hardware vendors, > Microsoft, Apple, and Google (with Chromebooks and Android) have been > doing for a while: faster boots, and S0 low power idle - and skip the > things making devs and users crazy. But I invite a persuasive contrary > argument. > > - Any other questions? > > > > [1] > https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/integrating-apps-with-modern-standby > [2] > https://twitter.com/hughsient/status/1225826488903249920 > [3] see line "beef up hibernation" > https://github.com/systemd/systemd/blob/master/TODO > -- > Chris Murphy > _______________________________________________ > desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
