This might be out of our hands as it was escalated to FESCo: https://pagure.io/fesco/issue/1873

I'd encourage anyone interested to attend tomorrow's FESCo meeting.

Workstation hasn't made any decisions yet, so it is premature for fesco to become involved (I'll say the same in the fesco ticket)

Some more considerations to ensure we have a good user experience when we enable autosuspend:

• We probably want to disable autosuspend when SSH is enabled. That would mitigate concerns regarding breakage when gdm in installed on servers. (One of my colleagues was quite disappointed by this new behavior the other day.) The main problem here is that changing the user setting doesn't work, you need to change the setting for the gdm user, and the easiest way to do that is to install a dconf override, which seems like too much work. Seems like this is FESCo's primary concern and they're likely to allow us to proceed if we are able to mitigate this problem. This code shows how to use systemd's D-Bus API to check if sshd.service is enabled. This seems superior to having a separate setting for Workstation and Server as you really never want your computer to autosuspend if you've enabled remote login.
• It's also reported to break multiseat, but halfline says multiseat is already broken in other ways, so maybe this is not a blocker.
• Idle inhibitors are still not fixed and it's looking very late to sneak a change of this magnitude into F28, so I still favor deferring this to F29 regardless.

Multiseat is really irrelevant here. it is not a feature that fedora supports in a meaningful way.
Can we drop that from this discussion, please ?

Edit: I can't reproduce on another system the "immediately suspends on logout from a GNOME session" behaviour previously mentioned in this comment.

However, I do still think that if auto-suspend retained as the default:

• There should be a prominent message on both fresh installation and upgrade that says "to comply with EU regulations, automatic suspend has been enabled. Depending on how you use your system, you may want to change this. [Leave enabled] [More info] [Disable auto-suspend]"
• There should also be a prominent button and/or info link in GNOME Settings->Power for change suspend settings system-wide. Not being able to revert this without having to resort to an externally documented series of commands is untenable.

I find the frequent notifications in VMs quite annoying: I don't really want to have to turn it off in every VM I install...

In today's Workstation WG meeting, we discussed this and agreed that:

15:26 < kalev> #agreed: Workstation WG discussed the new auto-suspend behaviour and decided to disable auto-suspend for F28. In rawhide (F29) we'll enable auto-suspend when battery powered only, and disable when plugged in. (+1:5, 0:0, -1:1)
15:27 < kalev> #action mcatanzaro to implement the auto-suspend behaviour changes

Ooops, looks like I accidentally volunteered to implement the auto-suspend only on battery behavior. :D That's the cost of trying to do two meetings at once, I guess. Sorry, can I walk this back please: I'd rather just do the urgent work to implement the override.

It should be easy enough to implement the battery power check, though, since upower already provides that information for us. @mclasen, can you find someone to handle that please?

Just as a side note, @mclasen - "Multiseat is really irrelevant here. it is not a feature that fedora supports in a meaningful way" is not my understanding at all. "Switch User" is an option right in the user menu on Workstation. I know there are multiple people who use it extensively on Fedora, because we get bug reports very promptly when it's broken. We even have a test case for it. So it sounds like there may be some mismatched expectations in this area.

Just as a side note, @mclasen - "Multiseat is really irrelevant here. it is not a feature that fedora supports in a meaningful way" is not my understanding at all. "Switch User" is an option right in the user menu on Workstation. I know there are multiple people who use it extensively on Fedora, because we get bug reports very promptly when it's broken. We even have a test case for it. So it sounds like there may be some mismatched expectations in this area.

@adamwill Multiseat and fast-user switching are two separate issues (though both are at play here). Multiseat is when you have two or more separate sets of input devices on the same system running concurrently (such as for some kiosks). It's kind of a bizarre setup, but people attempt it.

I'd like to point out this important comment from the fesco ticket:
https://pagure.io/fesco/issue/1873#comment-504339

It suggests that the motivation for pushing auto-suspend in the first place "EU says we have to" might be just a misunderstanding. I'd also add that Fedora not being sold as a product affects this as well (IANAL).

@sgallagh d'oh, thanks for the usual Monday morning correction :P

@kparal well, there's an overlap that may not be obvious to all Fedora folks here. One of the most significant GNOME downstreams these days is Endless, which is a hardware supplier. I believe this default was basically changed because Endless needed it to be, and the GNOME folks figured hey, may as well do it for everyone if Endless is going to have to do it. IMBW there, but that's my reading of what happened.

mcatanzaro> mclasen: I guess if you check for only-on-battery, that should fix VMs too?

agreed: ... In rawhide (F29) we'll enable auto-suspend when battery powered only

Checking for battery might not be enough for VMs. QEMU does pass battery information through to the guest, but other managers do [1]. I remember seeing battery information displayed in VMs, and it's a convenient thing for various reasons, so IMHO it's only a question of time before qemu supports this.

Supporting VMs properly most likely requires a separate check for virtualization, not relying on lack of battery power.

[1] https://pubs.vmware.com/workstation-9/index.jsp?topic=%2Fcom.vmware.ws.using.doc%2FGUID-489559B5-7C16-4C05-94BC-890AA7353A0E.html

Ooops, looks like I accidentally volunteered to implement the auto-suspend only on battery behavior. :D That's the cost of trying to do two meetings at once, I guess. Sorry, can I walk this back please: I'd rather just do the urgent work to implement the override.
It should be easy enough to implement the battery power check, though, since upower already provides that information for us. @mclasen, can you find someone to handle that please?

Actually there's already a separate GSetting for this, so that's easy to handle.

So once hadess's work in https://gitlab.gnome.org/GNOME/mutter/merge_requests/54 goes in, the only thing we'll be missing is the virtualization check.

OK, I'm closing this. Behavior in F28 will be to never auto suspend, behavior in F29 will be to auto suspend only when on battery power. Since there were already settings provided for this, it was just a matter of installing an override file.

Virtualization will probably be broken when qemu starts exposing battery status to the VM, but that can be treated as any other bug IMO, rather than as part of this issue.