feat(asusd): add PPD conflict detection warning

[scardracs]

Summary

This Pull Request resolves power profile contention between power-profiles-daemon (PPD) and asusd while providing seamless native compatibility for KDE Plasma and GNOME desktop power widgets.

Problem

When power-profiles-daemon and asusd run concurrently, PPD reacts to platform_profile changes made by asusd and silently resets CPU EPP to driver defaults (balance_performance), overriding configured EPP settings (profile_balanced_epp).

Solution

PPD Conflict Warning: asusd, rog-control-center, and asusctl check at startup if net.hadess.PowerProfiles is already owned on system D-Bus. If active, a prominent warning is logged instructing the user to disable power-profiles-daemon.service.

---

Detailed Changes

• rog-control-center/src/main.rs & asusctl/src/main.rs: Added startup PPD conflict warning checks.
• MANUAL.md & distro-packaging/asusctl.install: Updated manual documentation and installation scripts.

---

Verification & Testing

• cargo check --all-targets: Clean compilation across workspace crates.
• cargo test --all: All unit tests passing (100% pass rate).
• cargo clippy --all -- -D warnings: 0 warnings.
• cargo cranky: 0 warnings.
• cargo fmt --all -- --check: Formatting verified.
• Git Hooks: Pre-commit and pre-push hooks executed cleanly.

---

Closes #205

[qwertyman100]

Reporter of #205 here. Thanks for the quick turnaround on this @scardracs, and thanks @Ghoul4500 for weighing in on scope.

One note on testing first: RUST_LOG=debug cargo run -p rog-control-center only exercises the new warning block in the GUI — the net.hadess.PowerProfiles provider lives in asusd, so that run can't reach it. On my machine PPD is currently active and owns the name, so the warning is the only path that would fire. I'm happy to run it, but I want to flag something in the provider first, because I think it bears directly on @Ghoul4500's "we don't want to replace PPD and have to maintain that" concern.

HoldProfile / ReleaseProfile are stubs

In asusd/src/ppd_dbus.rs, hold_profile() returns cookie 1 without applying or tracking anything, release_profile() is a no-op, and ActiveProfileHolds is hardcoded to [].

Holds aren't a corner of the PPD interface — they're how powerprofilesctl launch, Steam/Lutris wrappers, GameMode and GNOME/KDE's own transient boosts all work. Every one of those calls HoldProfile, gets a success cookie back, and relies on the daemon releasing the hold when the client's D-Bus connection drops. Against this implementation they would all silently do nothing: no error, no profile change, no visible hold, nothing in any log the user would think to read.

That's the same silent-wrong-outcome failure mode that made the original bug in #205 so hard to diagnose — asusd wrote the right value, lost the race, and the only symptom was a wrong sysfs number.

For context on how visible this would be in practice: my own setup has 12 Steam titles plus a Heroic global wrapper running through powerprofilesctl launch -p performance -- %command%. Under this provider all of them would quietly stop boosting, and the only symptom would be worse frame rates.

Three smaller things

1. No PropertiesChanged for ActiveProfile on out-of-band changes. Nothing emits when the profile changes via fn+F5, asusctl profile set, or asusd's own change_platform_profile_on_ac AC/battery switching. PPD signals on every change, so a desktop widget would show a stale profile — visible on any plug/unplug, which is the most common profile change there is.
2. EPP is written before the profile is validated in set_platform_profile_from_ppd(): check_and_set_epp() and config.write() both run before the choices.contains(&policy) check, so an unsupported profile returns NotSupported having already changed EPP and persisted config.
3. D-Bus name-ownership policy. The system bus denies name ownership by default; net.hadess.PowerProfiles is ownable only because the power-profiles-daemon package ships the system.d policy file permitting it. If a user follows the new MANUAL.md guidance and removes PPD rather than just disabling it, that file goes too and asusd's request_name fails — the code warn!s and continues, so the feature quietly stops working. This direction would need asusctl to ship its own policy file.

Suggestion: split this PR

The warning half and the provider half have very different risk profiles, and right now they're bundled so the easy one is blocked by the hard one.

The warning is ~35 lines across three binaries, uncontroversial, and closes #205 outright — my residual ask on that issue was only ever a startup warning, and it would have saved me the several hours that produced the two corrections in that thread. That could merge now.

The net.hadess.PowerProfiles provider is the part that needs the discussion @Ghoul4500 described. Implementing PPD's semantics properly — hold refcounting, per-client tracking, release-on-disconnect, ActiveProfileHolds signalling, plus the D-Bus policy and packaging — is a substantially larger and ongoing commitment, since it then has to stay in step with PPD's own evolution. That's exactly the maintenance burden being weighed, and I don't think the current diff's scope reflects its true size.

Splitting would let the small win land while the larger question stays open on its own merits.

Happy to test anything useful on a G614FR (Ryzen 9 9955HX3D / RTX 5070 Ti, CachyOS, KDE Plasma) — including the warning path as-is, and the provider if the hold semantics get filled in.

[qwertyman100]

Thanks for splitting it @scardracs — this is now exactly what I was asking for in #205, and I'd be happy to see it merged as-is. I'm building the branch now and will report the warning output.

Two things the split left behind, both in the docs rather than the code:

1. Unterminated code fence in MANUAL.md

The closing fence was removed along with the provider sentence:

> ```bash
> sudo systemctl disable --now power-profiles-daemon.service

A common use of asusctl is to bind the `fn+f5` (fan) key...

The block never closes.

2. The manual still tells users to disable PPD, but the sentence that made that safe is the one that got removed

It previously continued: "asusd automatically provides the standard D-Bus interface net.hadess.PowerProfiles so KDE Plasma and GNOME desktop power sliders continue to work natively without power-profiles-daemon."

With the provider gone, a user who follows that instruction loses the desktop power slider, powerprofilesctl entirely, and every HoldProfile client — GameMode, Steam/Lutris wrappers, and the desktop environments' own transient boosts. The asusctl.install change compounds it: upgrades from 3.x no longer enable PPD either.

Suggestion: document both resolutions

The contention is fixed by having one writer, not by having a particular writer — so there are two symmetric resolutions, and the manual currently documents only the one that costs the user functionality:

• asusd owns it: disable PPD (what the manual says today). asusd applies its configured EPP, fan curves and PPT limits, but the DE slider and all hold-based boosting are gone.
• PPD owns it: leave PPD running and stop asusd writing EPP — platform_profile_linked_epp: false, plus change_platform_profile_on_ac: false and change_platform_profile_on_battery: false. No contention, and the slider, powerprofilesctl and GameMode holds all keep working. Configuration only, no code.

That second one is what I've run since diagnosing #205 and it's been stable — PPD owns net.hadess.PowerProfiles, asusd never writes EPP, and the wrong-EPP symptom is simply absent. Given the provider is now out of scope, it might be worth the manual presenting both and letting the user choose which daemon owns the hardware, especially since the new warning points only at the first.

(For the record, I think dropping the provider was the right call — my HoldProfile note was about how much was left to do, not an argument for doing it.)

[qwertyman100]

Tested as promised. Built 3175cc16 (rustc 1.97.1), ran against a live asusd 6.3.10 with PPD 0.30 active.

rog-control-center — RUST_LOG=debug cargo run -p rog-control-center, first six lines of output:

[WARN  rog_control_center] ********************************************************************************
[WARN  rog_control_center] WARN: 'power-profiles-daemon' is active on system D-Bus!
[WARN  rog_control_center] Running power-profiles-daemon concurrently causes EPP and platform_profile contention.
[WARN  rog_control_center] To allow asusd to manage profiles, EPP, fan curves, and KDE/GNOME sliders natively, disable it:
[WARN  rog_control_center]   sudo systemctl disable --now power-profiles-daemon.service
[WARN  rog_control_center] ********************************************************************************
[INFO  rog_control_center] Running on G614FR, product: ROG Strix G16

asusctl — asusctl profile get:

WARN: 'power-profiles-daemon' is running concurrently with asusd!
This causes EPP and platform_profile contention.
Disable it via: 'sudo systemctl disable --now power-profiles-daemon.service'
Active profile: Balanced

Detection works, fires first thing, correctly identifies the name owner. Nothing was mutated by either run (config file md5 unchanged, platform_profile/EPP unchanged, PPD kept the same bus connection). ✅ Works for me — this would have saved me the investigation in #205.

One observation from the test, which ties into my previous comment. My machine is deliberately configured the other way round — PPD owns the hardware and asusd is configured not to write EPP:

platform_profile_linked_epp:        false
change_platform_profile_on_ac:      false
change_platform_profile_on_battery: false

In that configuration there is no contention — asusd never writes EPP, so nothing races — yet the warning fires anyway, on every single asusctl profile invocation including read-only ones like get. So as written it's a false positive for anyone who resolved #205 by making PPD the sole writer rather than by disabling it.

Cheap fix if you think it's worth it: gate the warning on asusd actually being configured to write, i.e. only warn when PPD is present and (platform_profile_linked_epp || change_platform_profile_on_ac || change_platform_profile_on_battery). Then it fires exactly when the two daemons will genuinely contend, which also makes the message strictly more trustworthy.

Not a blocker either way — I'd still merge this as-is.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Summary by CodeRabbit

• Documentation
  • Updated Profiles documentation to explain ACPI-based power profile management.
  • Removed outdated prerequisites and kernel patch references.
  • Added guidance for preventing conflicts between power profile services, including configuration options and commands.
  • Added a Power Profiles section to the README with configuration guidance and links to the manual.

Walkthrough

The documentation states that asusd manages power profiles through ACPI platform_profile drivers. It removes obsolete prerequisites, documents daemon contention, and links the README to the configuration guidance.

Changes

Power profile management documentation

Layer / File(s)	Summary
Profile management guidance and README integration MANUAL.md, README.md	Documents asusd profile management, daemon contention warnings, and commands to disable power-profiles-daemon or asusd profile-management settings. The README adds a Power Profiles section linking to the manual.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Suggested labels: documentation

Suggested reviewers: neroreflex

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR adds conflict detection for [#205], but it does not fix the linked issue's underlying EPP failure during platform-profile transitions.	Fix the EPP transition behavior, or clarify that [#205] accepts conflict detection and user guidance as the complete resolution.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: adding a power-profiles-daemon conflict warning.
Description check	✅ Passed	The description explains the problem, solution, affected components, linked issue, and verification results, but omits tested hardware and environment details.
Out of Scope Changes check	✅ Passed	The documentation and installation changes concern power-profile daemon conflicts and support the stated PR objectives.

---

_{Comment @coderabbitai help to get the list of available commands.}

[Ghoul4500]

I'm mostly happy with this. but fold it into just 2 commits instead of these 3 one for readme and one for warnings, and then improve the wording to say any power profiles daemon is running, not necessarily ppd. There is one part that does this somewhat well. Consider disabling all EPP related features if any such daemon is running, since this would currently warn and proceed to conflict

[coderabbitai]

Actionable comments posted: 6

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@asusd/src/ctrl_platform.rs`:
- Around line 241-250: Update check_and_set_epp’s D-Bus ownership probe so every
failure to connect, create DBusProxy, parse the PowerProfiles BusName, or query
name_has_owner is logged and causes an immediate return. Fail closed by
proceeding to the EPP write only when ownership is successfully confirmed
absent; remove the unwrap_or(false) fallback.
- Around line 241-250: Update update_policy_ac_or_bat to check whether
net.hadess.PowerProfiles owns its D-Bus name before calling
set_platform_profile, and return before both platform_profile and EPP writes
when ownership is detected. Ensure check_and_set_epp does not bypass this
protection when change_epp is false; reuse the existing ownership-detection
logic rather than checking only after the platform profile write.
- Around line 241-250: The synchronous D-Bus owner check inside
check_and_set_epp must not block the async executor. Move the PowerProfiles
ownership probe into an async helper using zbus::fdo::DBusProxy with
self.connection, or run the existing blocking probe via spawn_blocking with an
explicit timeout, then preserve the early return when the daemon owns
net.hadess.PowerProfiles.

In `@asusd/src/daemon.rs`:
- Around line 176-183: Update the ppd_owned warning condition to reflect whether
asusd’s profile-related controls are actually enabled, including the
platform-profile path, rather than relying only on D-Bus ownership. Identify the
owning provider through D-Bus when possible, and make the remediation
provider-specific or provider-neutral instead of always naming
power-profiles-daemon.service.

In `@MANUAL.md`:
- Around line 80-83: Insert a blank quoted Markdown line between the explanatory
paragraph and the opening fenced command in the asusd platform-profiles
documentation section, resolving MD031 while preserving the existing command and
closing fence.
- Around line 74-83: Update the Power Profiles Daemons compatibility section in
MANUAL.md to document the alternative ownership mode: users may keep PPD active
while disabling asusd’s platform-profile-linked EPP and AC/battery
profile-change settings, allowing PPD to own those controls. Preserve the
existing instructions for users who want asusd to manage them.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 14cb48e8-f7f5-4e4b-838b-ee33d3011a96

📥 Commits

Reviewing files that changed from the base of the PR and between e36a23f and 741f915.

📒 Files selected for processing (3)

• MANUAL.md
• asusd/src/ctrl_platform.rs
• asusd/src/daemon.rs

📜 Review details

🧰 Additional context used

🪛 markdownlint-cli2 (0.23.1)

MANUAL.md

[warning] 81-81: Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

asusd/src/ctrl_platform.rs (1)

539-566: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Platform-profile writes bypass the PPD ownership guard in two zbus-exposed methods. check_and_set_epp's internal is_power_profiles_daemon_active() check only gates the EPP write it performs. It does not stop the caller's separate self.platform.set_platform_profile(...) call, so both methods still write platform_profile while PPD is active. set_platform_profile_on_ac and set_platform_profile_on_battery call set_platform_profile and inherit this gap.

• asusd/src/ctrl_platform.rs#L539-L566: In next_platform_profile, call is_power_profiles_daemon_active() before Line 552 and return without changes (for example, return an FdoErr::Failed describing the conflict) when it is true, before reaching self.platform.set_platform_profile(policy.into()) at Line 553.
• asusd/src/ctrl_platform.rs#L579-L614: In set_platform_profile, call is_power_profiles_daemon_active() before Line 589 and return the same way before self.platform.set_platform_profile(policy.into()) at Lines 598-599.

🐛 Proposed fix pattern (apply to both sites)

     async fn next_platform_profile(
         &mut self,
         #[zbus(signal_context)] ctxt: SignalEmitter<'_>,
     ) -> Result<(), FdoErr> {
         let policy: PlatformProfile =
             platform_get_value!(self, platform_profile, "platform_profile").map(|n| n.into())?;
         let choices =
             platform_get_value!(self, platform_profile_choices, "platform_profile_choices")?;
         let policy = PlatformProfile::next(policy, &choices);

         if self.platform.has_platform_profile() {
+            if self.is_power_profiles_daemon_active().await {
+                return Err(FdoErr::Failed(
+                    "Power profiles daemon is active; refusing to change platform_profile".to_owned(),
+                ));
+            }
             let change_epp = self.config.lock().await.platform_profile_linked_epp;
             let epp = self.get_config_epp_for_throttle(policy).await;
             self.check_and_set_epp(epp, change_epp).await;
             self.platform
                 .set_platform_profile(policy.into())

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@asusd/src/ctrl_platform.rs` around lines 539 - 566, Platform-profile writes
bypass the PPD ownership guard in both zbus methods. In
asusd/src/ctrl_platform.rs lines 539-566, update next_platform_profile to call
is_power_profiles_daemon_active() before self.platform.set_platform_profile and
return the same conflict FdoErr without changing state when active; apply the
same guard before the write in set_platform_profile at lines 579-614.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@asusd/src/daemon.rs`:
- Around line 186-228: The provider name lookup in the warning flow should read
`/proc/{pid}/exe` instead of `/proc/{pid}/comm`. Update the
`std::fs::read_to_string` call near `provider_name` to resolve the executable
path and derive the executable filename, preserving the existing trimming and
service-name construction so `power-profiles-daemon` produces the correct unit.

---

Outside diff comments:
In `@asusd/src/ctrl_platform.rs`:
- Around line 539-566: Platform-profile writes bypass the PPD ownership guard in
both zbus methods. In asusd/src/ctrl_platform.rs lines 539-566, update
next_platform_profile to call is_power_profiles_daemon_active() before
self.platform.set_platform_profile and return the same conflict FdoErr without
changing state when active; apply the same guard before the write in
set_platform_profile at lines 579-614.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a649fea6-6176-43be-b59b-560533a9bac9

📥 Commits

Reviewing files that changed from the base of the PR and between 741f915 and 8703d66.

📒 Files selected for processing (3)

• MANUAL.md
• asusd/src/ctrl_platform.rs
• asusd/src/daemon.rs

📜 Review details

🔇 Additional comments (8)

asusd/src/daemon.rs (3)

129-139: LGTM!

---

165-184: LGTM!

---

200-215: LGTM!

Also applies to: 229-234

MANUAL.md (1)

74-94: LGTM!

asusd/src/ctrl_platform.rs (4)

236-270: LGTM!

---

272-303: LGTM!

---

400-428: LGTM!

---

707-751: LGTM!

Also applies to: 869-930, 962-1158

[Ghoul4500]

I'm mostly happy with this. but fold it into just 2 commits instead of these 3 one for readme and one for warnings, and then improve the wording to say any power profiles daemon is running, not necessarily ppd. There is one part that does this somewhat well. Consider disabling all EPP related features if any such daemon is running, since this would currently warn and proceed to conflict

I think I'm to blame on this one for being a bit vague. I meant in rogcc and asusctl CLI we can disable changing EPP settings if PPD is detected, and give some feedback to user side. But at the same time, it does feel like more work than it's worth.

You can consider it but if it's a big change, I would rather just keep the warning in readme and drop all code change for now and think of a better permanent solution in time. I need to take a look at the EPP changes mario has been working on for that

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@MANUAL.md`:
- Around line 82-94: Update the daemon ownership instructions in the “Allow an
external daemon” option so they refer to the user’s selected external daemon,
either PPD or Tuned, rather than always instructing users to keep
power-profiles-daemon active. Keep the existing power-profiles-daemon disable
command under the asusd option and label it as an example for PPD users.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2081bc60-6178-4c29-88a3-8da35a4985f5

📥 Commits

Reviewing files that changed from the base of the PR and between 8703d66 and 2752df5.

📒 Files selected for processing (1)

• MANUAL.md

📜 Review details

🔇 Additional comments (1)

MANUAL.md (1)

74-81: LGTM!

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@README.md`:
- Around line 26-29: Update the “Power Profiles” section in README.md to
accurately state that asusd or an external power-profile daemon manages power
profiles, replacing the ambiguous “ppds” wording. Retain and clarify the Manual
link as the source for ownership options and warnings about conflicting daemons.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b6b60813-d180-4b45-8573-2205510f132c

📥 Commits

Reviewing files that changed from the base of the PR and between 8cedd35 and 29e5143.

📒 Files selected for processing (2)

• MANUAL.md
• README.md

📜 Review details

🔇 Additional comments (2)

MANUAL.md (2)

88-88: Refer to the selected external daemon.

Line 88 still labels the option PPD/Tuned but tells users to keep power-profiles-daemon active. If the user selects tuned, this instruction is incorrect. Refer to the selected daemon, and keep the PPD command only under the asusd ownership option.

---

74-87: LGTM!

Also applies to: 90-94

[Ghoul4500]

This looks good. Thank you for the contribution