#191 Enable power-profiles-daemon by default
Closed: Fixed 10 months ago by catanzaro. Opened 2 years ago by hadess.


Metadata Update from @chrismurphy:
- Issue tagged with: meeting

2 years ago

Discussed in today's meeting, it's too late to consider this for Fedora 33.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting
- Issue set to the milestone: Fedora 34

2 years ago

Discussed in today's meeting, it's too late to consider this for Fedora 33.

I didn't ask for this to be considered for F33. Is it OK for rawhide?

Probably, though we didn't agree to that yet.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

2 years ago

Is there any reason why this wasn't discussed at the last meeting, as uncontroversial as it is?

Schedule. ;) Just didn't get to it. Since you only requested F34, we focused on F33 items yesterday. I've requested this topic for next week.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

2 years ago

This is approved for F34.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

2 years ago

This should be implemented. We just need to test that it worked.

Metadata Update from @hadess:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

So this package was built, but unfortunately the change was never actually implemented in that power-profiles-daemon was not actually installed by anything. Bastien finally noticed and changed that this week by adding a Recommends: to gnome-control-center: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e8036e004e.

Problem is, we now have less than a week until final freeze. It's going to take a few days to get the gnome-control-center out to users, so realistically user testing is not going to begin until after the freeze has already started. We should not be adding new system daemons at this point in the development cycle. Please defer this to F35.

The update I made I pulled, and I reverted the change. Somebody that is the reason why I can't participate in the fedora-desktop list created that last one with Recommends. I recommend that you reach out to them.

Yeah I know, you reverted the change when I requested it and Pete un-reverted it, likely by mistake. I'll go ahead and undo that now.

We are good to go for F35 though!

We discussed this in the Bodhi update and the conclusion was to keep the recommends for F34 as well.

There aren’t really supposed to be major changes between the beta release and the final freeze anyway.

We discussed this in the Bodhi update and the conclusion was to keep the recommends for F34 as well.

Reopening this ticket, because that is not the conclusion of our discussion in the ticket. Pete, you do not get to unilaterally add a new system daemon to Fedora Workstation. You just don't. Especially not in the week before final freeze.

This will be top of the agenda for the Workstation WG meeting on Tuesday, April 6. If we have to request a freeze break to undo your update, I will ask the Working Group to ask FESCo to remove your commit access to gnome-control-center.

I'm especially confused why you're doing this since the change is already in F35 and it is uncontroversial there....

Metadata Update from @catanzaro:
- Issue status updated to: Open (was: Closed)
- Issue tagged with: meeting

a year ago

Huh? Of course I get to decide what happens in my package.

You just storm in and undo changes other contributors have done and proclaim that anything else is wrong and just override the package maintainer.

I'd respect the decision if it came from the wg but it is just one loud person here who doesn't know how to talk nicely to other people. So far from what I can see is that the wg asked to add the package and catanzaro is just being a jerk and rejecting hadess and my changes. ESPECIALLY SINCE IT IS NOT YOUR PACKAGE

I am very close to asking the wg to remove your access to the gnome sig. Or bringing fesco in because this is just ridiculous.

I wonder how many contributors catanzaro has managed to drive away over the years...

Pete, you're failing to apply common sense here. You know that gnome-control-center is installed by default in Fedora Workstation. You know that adding a new Recommends to your package will cause the Recommends to also be installed by default. You know the Workstation WG decides what is allowed to be installed by default, and you also know that we're not likely to approve major changes like adding a new system daemon in the week before final freeze. And yet you've done it anyway.

Now a user has reported that power-profiles-daemon is causing a severe performance regression in its default configuration. It's switching the CPU governor when not plugged in. This bug report only arrived today because it wasn't previously installed by default until yesterday, so it naturally did not receive any testing from Fedora beta testers. I have no doubt that problem will be addressed eventually, but it's just not something we are plausibly able to deal with in the week prior to final freeze. In fairness, this regression is due to Bastien's update rather than yours, because your update hasn't reached stable yet, but when I contacted Bastien to express my concerns, he worked with me and reverted his change in F34, leaving it only in rawhide where users have plenty of time to test it. By reverting my attempts to revert it, you're blocking us from fixing this, and every day that passes just increases the number of beta testers who wind up with this package installed....

If you want me to contact you before touching "your package," which is collaboratively maintained by the entire GNOME SIG, then please join #fedora-desktop on irc.gnome.org. This is where we discuss GNOME packaging changes. Please note that all members of the SIG are authorized to commit to any package that it owns, and I'm not aware of it being an issue prior to today.

One more thing. I would very much appreciate it if you could clean this up by removing the Recommends: from the F34 package, creating a bodhi update for that, and then waiting until next week so the WG (and, if necessary, FESCo) can decide what to do about this.

If you don't immediately create this update, then beta users who upgrade Fedora between now and next week are going to have power-profiles-daemon installed, and we don't have any easy way to uninstall it. The most practical solution is to leave it installed and flip its preset to disabled in F34 so that it does not start, which will be annoying for users who intentionally install it. I would rather not need to touch the presets. If you remove the Recommends now, we can avoid the need for that.

It's being discussed on Reddit already.

My first preference, overwhelmingly, is to have access to a time machine to get the change in before Fedora 34 beta freeze.

Consider that the working group decided on the day Fedora 33 Beta was released, that this feature was too late for Fedora 33. And it is quite a bit later in the cycle this time. It's not a big deal to miss the 34 boat, there is another ship sailing soon.

My suggestion is we vote in the ticket rather than stringing this out a week.

Proposal: the feature still sounds like a good idea! Let's do it for Fedora 35!

Now a user has reported that power-profiles-daemon is causing a severe performance regression in its default configuration. It's switching the CPU governor when not plugged in.

The "severe performance regression" is a cosmetic problem with gnome-shell's animation framework, and power-profiles-daemon is not switching the CPU governor.

but when I contacted Bastien to express my concerns, he worked with me and reverted his change in F34

No, I didn't "work with you". You left me no choice but to revert it, with no path to asking for an exception either. I didn't notice that I missed out on adding power-profiles-daemon to the default install, but so did the WG as a whole. To say that I'm not happy being told "see you in 6 months" is an understatement.

Can we get this sorted out without so much yelling at each other and pointing fingers?

I understand that people are frustrated that this didn't land in time, but let's see if we can come up with the best solution for users here.

Bastien, what would be your preference here? Ship it in F34 at this point? If we have your preference I think the next step is for the Workstation WG to vote on the path to take for F34.

Pete and Michael, I understand you rubbed each other the wrong way - maybe just take a step back and breathe some fresh air and let the Workstation WG decide here please. And maybe next time just talk to each other before pushing reverts back and forth :)

Bastien, what would be your preference here? Ship it in F34 at this point? If we have your preference I think the next step is for the Workstation WG to vote on the path to take for F34.

I'd really rather it shipped with F34, yes, and I guess Fedora's hardware partners as well :)
It might also be helpful to add a quick discussion to the agenda, on how to avoid this kind of problems with WG backed changes slipping through the cracks.

OK, so now that we know Bastien's recommendation, I think the next step is to decide what to do. I'll note that if we should end up enabling it for F34, there is still a path to take it out again during the final freeze if signification problems come up.

Workstation WG members, please vote to indicate your support (+1 or -1) for the following:

Ship power-profiles-daemon on F34 install media

(I don't want to cut off discussion here, just trying to organize it a bit so that we can get some kind of decision before the freezes start. Just continue the discussion please if anyone has something more to say/ask.)

I am against adding it as the last minute without testing in the diverse configurations that Fedora users have. It is unfortunate that we failed (and by we I mean the WG here) to get this in by beta to give it that testing.

so, -1 from me.

Even if we don't install it by default in F34, we can advertise it as something that is available for users to opt into, with a blog post or magazine article, and make it available out of the box in F35.

I am against adding it as the last minute without testing in the diverse configurations that Fedora users have. It is unfortunate that we failed (and by we I mean the WG here) to get this in by beta to give it that testing.

Even if the goal is laudable, I find it weird that something like systemd 248 can land in the last week before the freeze, but that a single daemon with an extensive test suite can't.

I'm -1 here, though I'm open to having my mind changed. I think pushing this change at this point goes against what we're trying to achieve with the Beta/Freeze process and there is some (small) chance of unanticipated serious problems popping up.

Even if the goal is laudable, I find it weird that something like systemd 248 can land in the last week before the freeze, but that a single daemon with an extensive test suite can't.

It looks like a systemd-248 release candidate was shipped with the Beta - so hopefully no new functionality is introduced by the final update. But yes, there's risk in all sorts of changes that we make in Fedora - both before and after release - and we can only try to find the best balanced approach.

It's great that power-profiles-daemon has an extensive test suite. How do you handle hardware variations in the test suite?

Are there any other distributions shipping power-profiles-daemon at this time? https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues looks quite quiet, but I can't tell the balance between a) no issues to worry about b) not very tested yet.

It's great that power-profiles-daemon has an extensive test suite. How do you handle hardware variations in the test suite?

We use python-umockdev and dbusmock to launch separate D-Bus sessions where we run the daemon and manipulate its D-Bus API, and see the results in D-Bus and in the sysfs files, or vice-versa.

Are there any other distributions shipping power-profiles-daemon at this time?

It's in Ubuntu and Arch.

https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues looks quite quiet, but I can't tell the balance between a) no issues to worry about b) not very tested yet.

It's quiet because it's stable and kernel support was late in arriving for the platform_profile API support. The Intel P-State driver is well tested. It basically does nothing but offer a D-Bus API with a bunch properties on a lot of systems.

Are there any other distributions shipping power-profiles-daemon at this time?

It's in Ubuntu and Arch.

Hmm, I think I asked the wrong question - I wanted to know if it's installed by default on any other distributions - to see if we can figure out the degree of real world testing. It looks like Ubuntu and Arch have packages of version 0.1 available, but I don't see any obvious evidence of it being installed by default.

https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues looks quite quiet, but I can't tell the balance between a) no issues to worry about b) not very tested yet.

It's quiet because it's stable and kernel support was late in arriving for the platform_profile API support. The Intel P-State driver is well tested. It basically does nothing but offer a D-Bus API with a bunch properties on a lot of systems.

So there are two backends - the Intel P-State Driver, and the "Platform Profiles" driver which uses this new kernel API?

My main concern wouldn't really be that your daemon is buggy, but that it would change the setting in such a way to exercise parts of kernel/hardware in untested combinations. I don't know how to get get that testing without rolling it out to users in a controlled fashion. :-(

-1

I will add it to F35 comps, though, so we don't need to rely on just the Recommends to ensure it gets installed in F35.

I don't think it's necessary to add it to comps, it just adds two paths that pull it in. I'd rather have consumers pull it in instead.

I'm generally not inclined to punish @hadess for our fault in not shipping this early. If @hadess is willing to be responsive to issues during the freeze period to fix things, then I'm fine with shipping it.

I'm also inclined to believe that adding it won't be as much of an issue as @catanzaro or @mclasen believe.

Moreover, having out of the box improved power management is something we need now that we ship on computers.

My main concern wouldn't really be that your daemon is buggy, but that it would change the setting in such a way to exercise parts of kernel/hardware in untested combinations. I don't know how to get get that testing without rolling it out to users in a controlled fashion. :-(

Fedora's hardware partners have tested it, and you can be sure that the bugs will get exercised in the kernel, whether or not we provide a UI for it.

its not about punishment at all. More about managing risk and following process. But I am open to be persuaded, just as Owen.

Fedora's hardware partners have tested it, and you can be sure that the bugs will get exercised in the kernel, whether or not we provide a UI for it.

Can you describe the overlap between:
* Systems where the "platform profiles" API will be exposed by the kernel
* Systems shipped by our hardware partners?

Fedora's hardware partners have tested it, and you can be sure that the bugs will get exercised in the kernel, whether or not we provide a UI for it.

Can you describe the overlap between:
Systems where the "platform profiles" API will be exposed by the kernel
Systems shipped by our hardware partners?

I don't have a full list of which devices have this feature in firmware, and which ones will eventually ship it, but I know that at least the Lenovo X1 laptop mentioned in this announcement, as well as some unlisted Ideapad laptops, will ship that feature in the firmware, and in the 5.11 kernel that Fedora 34 will ship.

Adding power-profiles-daemon adds a nice UI on top of the kernel feature that's already there.

The platform_profile kernel API which will also be used by HP laptops that support its WMI interface, and a number of Microsoft Surface devices. I expect support for more hardware to land during the lifecycle of Fedora 34.

I'm generally not inclined to punish @hadess for our fault in not shipping this early. If @hadess is willing to be responsive to issues during the freeze period to fix things, then I'm fine with shipping it.

If a decision is made before end of business Friday (tomorrow), I can move the days off I had planned to take next week, it's not like I can go anywhere anyway, although I really don't expect anything major to happen, and I'll likely work on some tweaks to the behaviour we've been discussing with designers.

I think i have to -1.

I'm +1 because I agree with @ngompa on needing something asap. I am +1 because it sounds like the WG dropped the ball (but I am not sure I agree from anecdotal experience). However, I am -1 because i agree with @mclasen and if we can just always skip the process, whats the point of the process. I am also generally -1 because we already have a power management daemon in fedora that works very well although it is not enabled by default (would love if it had a GUI).

I don't have a full list of which devices have this feature in firmware, and which ones will eventually ship it, but I know that at least the Lenovo X1 laptop mentioned in this announcement, as well as some unlisted Ideapad laptops, will ship that feature in the firmware, and in the 5.11 kernel that Fedora 34 will ship.

How would someone check if the API is present on their device. If/sys/firmware/acpi/platform_profile_choices exists, is the API present? We could potentially mail devel and test and ask people running 5.11 to check, and if so, do testing on PPD.

That all being said, this is really late to introduce a new software component and there always can be unanticipated bugs as well as the kind of bugs we might expect. Can we quickly review the harm in not shipping this. Is it simply that users don't get the profile selection UI in the control center, or will things work less well out of the box? [sorry for being lazy here and not re-reviewing everything again]

Fedora's hardware partners have tested it, and you can be sure that the bugs will get exercised in the kernel, whether or not we provide a UI for it.

We can be confident it was not tested enough due to the GNOME Shell animation performance regression that was reported yesterday, one day after it was added to the default install. Serious testing in Fedora did not begin until it was added to the default install.

Now, you fixed that issue almost immediately after it was reported. Thanks for that. I'm very confident in your ability to handle any problems reported to you. The problem is with final freeze on Tuesday, we're simply out of time.

I think I am leaning towards -1 as well, for the same reasons as otaylor. Would be really sad to not see this land, but at the same time, I think I agree that it opens up the possibility of exposing regressions in kernel and gnome-shell (such as https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/28 that mcatanzaro pointed out above).

I think I am leaning towards -1 as well, for the same reasons as otaylor. Would be really sad to not see this land, but at the same time, I think I agree that it opens up the possibility of exposing regressions in kernel and gnome-shell (such as https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/28 that mcatanzaro pointed out above).

That work-around for gnome-shell is already fixed, and the update is available:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-282bca5bc2

I think I am leaning towards -1 as well, for the same reasons as otaylor. Would be really sad to not see this land, but at the same time, I think I agree that it opens up the possibility of exposing regressions in kernel and gnome-shell (such as https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/28 that mcatanzaro pointed out above).

This makes the assumption that the feature isn't being used in the background. It definitely is being used, regardless of whether we ship the frontend. The difference is that there's no control for it unless we ship this.

And the question of regressions honestly doesn't matter to me if @hadess is fixing them as fast as he is currently doing so. We're not in freeze, and @hadess is committing to actively working to fix things, and I trust his statement that our hardware partners are actively working on this and working with him on this.

If we were in freeze right now, then I would agree with deferring it. But we're not, and I think we're being overly cautious. This isn't like malcontent where everything is just utterly broken because nobody clearly thought through the UX for parental controls. This is something that has been actively developed in concert with OEMs and ODMs to ensure that things work.

I'm reminded of the bottleneck statement here, and we should have a bias for action here to deliver features that our stakeholders need. That's why I say we should ship it.

OK, I count: +1:1, -1:5, so it looks like it's going to have to be postponed to F35. I'll email pwalter and work with him to get the gnome-control-center packaging updated to not pull power-profiles-daemon in for F34.

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue set to the milestone: Fedora 35 (was: Fedora 34)
- Issue tagged with: pending-action

a year ago

I am also generally -1 because we already have a power management daemon in fedora that works very well although it is not enabled by default (would love if it had a GUI).

I think that you might be confused about what power-profiles-daemon does. We don't have anything in the default install that does what it does, otherwise we wouldn't have needed to create a new daemon just for that ;)

The screenshot in this post is an example of what the daemon allows:
http://www.hadess.net/2020/09/power-profiles-daemon-new-project.html

Metadata Update from @kalev:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Metadata Update from @catanzaro:
- Issue untagged with: pending-action

a year ago

Also please make it a F35 Change, thank you

I am also generally -1 because we already have a power management daemon in fedora that works very well although it is not enabled by default (would love if it had a GUI).

I think that you might be confused about what power-profiles-daemon does. We don't have anything in the default install that does what it does, otherwise we wouldn't have needed to create a new daemon just for that ;)

We have never shipped the tuning daemon (tuned) in Fedora Workstation because it lacks a GUI.

Also please make it a F35 Change, thank you

I agree this deserves a change proposal.

Status update: the feature is implemented for F35, but the value of the setting is set only for the current boot. So it gets reset each time you reboot.

There is an upstream ticket for this here where upstream is debating whether this behavior is desired or not. I'll note this is the only non-persistent setting in System Settings.

@hadess has a merge request to fix this. IMO power-profiles-daemon will be fine for F35 provided this MR gets merged soon. It's confusing and not very useful otherwise.

The other problem is that we're still missing a F35 change proposal, and the deadline for systemwide changes has actually passed already. I think it would be better to submit a change proposal late than not at all. The change proposal is important because otherwise power-profiles-daemon won't be promoted at all (no release notes or other publicity).

Please go ahead and submit a Change now. We can carry MRs downstream as needed.

At this point, the change has been implemented, but without an approved change proposal. My recommendation is to submit a late system-wide change proposal to FESCo and petition for it to be approved late. FESCo makes exceptions on occasion and I think they may be willing to do so in this case because (1) the change is already implemented, and (2) the change was previously deferred from F34 to F35 and it would be unfortunate for it to be deferred yet again to F36.

But the change proposal really is not optional. Reopening so we don't lose track of this paperwork issue.

@hadess has a merge request to fix this. IMO power-profiles-daemon will be fine for F35 provided this MR gets merged soon. It's confusing and not very useful otherwise.

This is fixed in power-profiles-daemon 0.9.0, so I no longer have any technical concerns about power-profiles-daemon. This is just a paperwork issue now.

Metadata Update from @catanzaro:
- Issue status updated to: Open (was: Closed)

10 months ago

@catanzaro Can you make the Change proposal?

Hello,

I've been made aware of the more recent demands for a Change proposal to be made. I won't be making one. The changes were accepted 6 months ago, didn't actually get pulled into the distribution because of an oversight, and now I'm being made to go through the motions again.

In addition to the work being requested, I also do not want to participate in discussions on the fedora-desktop ("workstation") list where I've been harassed and insulted, and that the Fedora Code of Conduct committee didn't deem worth their time to look into.

Ubuntu ships power-profiles-daemon since their April 2021 release, where it's pulled in by the gnome-control-center package:
https://packages.ubuntu.com/search?keywords=power-profiles-daemon&searchon=names&suite=all&section=all

They didn't seem to mind decisions about whether the daemon should remember its state being taken upstream rather than downstream.

Hello,

I've been made aware of the more recent demands for a Change proposal to be made. I won't be making one. The changes were accepted 6 months ago, didn't actually get pulled into the distribution because of an oversight, and now I'm being made to go through the motions again.

This is not a recent thing, we've always required Change documents for this sort of thing.

In addition to the work being requested, I also do not want to participate in discussions on the fedora-desktop ("workstation") list where I've been harassed and insulted, and that the Fedora Code of Conduct committee didn't deem worth their time to look into.

Please stop accusing us of malice. The whole reason we want the Change document is for visibility. But since you won't do it, I guess I will have to. Be warned that you're getting listed as the Change owner anyway.

Ubuntu ships power-profiles-daemon since their April 2021 release, where it's pulled in by the gnome-control-center package:
https://packages.ubuntu.com/search?keywords=power-profiles-daemon&searchon=names&suite=all&section=all

They didn't seem to mind decisions about whether the daemon should remember its state being taken upstream rather than downstream.

You know that's not true, given that Ubuntu customizes the GNOME desktop considerably for usability reasons.

I decided to help write the change after all, since it really is required and I don't want to see this slip yet again.

Please stop accusing us of malice. The whole reason we want the Change document is for visibility. But since you won't do it, I guess I will have to. Be warned that you're getting listed as the Change owner anyway.

Of course, we can remove your name if you don't want it there, but you did all the work except for this final paperwork, so I guess you probably want some credit.

This is not a recent thing, we've always required Change documents for this sort of thing.

It didn't seem to be a requirement when this was discussed and approved for Fedora 33.

Please stop accusing us of malice.

I have no idea what this is in response to.

In any case, thanks Michael for volunteering to do the Change proposal. Let me know if you have any questions.

Well Neal helped too. If you could review and approve the change proposal, that would be great, thanks.

Well Neal helped too. If you could review and approve the change proposal, that would be great, thanks.

I've tweaked it (power-profiles-daemon changes between system profiles, not CPU profiles).

OK thanks. With that, the Workstation side of this is complete again... unless the change gets rejected, but that's unlikely. Especially since it only affects Workstation, so in theory FESCo approval is just a formality.

Metadata Update from @catanzaro:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

10 months ago

Login to comment on this ticket.

Metadata