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.