Here's a patch to apply to mangohud-0.7.2-r1 that makes both packages work with each other. --- a/src/cpu.cpp +++ b/src/cpu.cpp @@ -510,7 +510,7 @@ bool CPUStats::GetCpuFile() { find_input(path, "temp", input, "Package id 0"); break; } - else if ((name == "zenpower" || name == "k10temp")) { + else if ((name == "zenpower" || name == "zenstats" || name == "k10temp")) { if (!find_input(path, "temp", input, "Tdie")) find_input(path, "temp", input, "Tctl"); break; @@ -633,7 +633,7 @@ bool CPUStats::InitCpuPowerData() { if (name == "k10temp") { cpuPowerData = (CPUPowerData*)init_cpu_power_data_k10temp(path); - } else if (name == "zenpower") { + } else if (name == "zenpower" || name == "zenstats") { cpuPowerData = (CPUPowerData*)init_cpu_power_data_zenpower(path); break; } else if (name == "zenergy") {
Make a PR upstream with the patch.
(In reply to Kostadin Shishmanov from comment #1) > Make a PR upstream with the patch. No. It belongs in FILESDIR because it's a problem entirely caused by downstream packaging.
The original zenpower project is dead if look at the ebuild I using a fork of the project. For some reason that fork rename the sensor to zenstat instead of zenpower. So just send that patch upstream, me and Adel will not mantained it.
(In reply to Gonçalo Negrier Duarte from comment #3) > The original zenpower project is dead if look at the ebuild I using a fork > of the project. > For some reason that fork rename the sensor to zenstat instead of zenpower. > > So just send that patch upstream, me and Adel will not mantained it. Being fare I gonna change the zenpower3 to this repo instead: https://github.com/koweda/zenpower3 So this patch is not needed.
(In reply to Gonçalo Negrier Duarte from comment #4) > (In reply to Gonçalo Negrier Duarte from comment #3) > > The original zenpower project is dead if look at the ebuild I using a fork > > of the project. > > For some reason that fork rename the sensor to zenstat instead of zenpower. > > > > So just send that patch upstream, me and Adel will not mantained it. > > Being fare I gonna change the zenpower3 to this repo instead: > https://github.com/koweda/zenpower3 > So this patch is not needed. But why tho? The fork that is currently used also has support for AM5. Just let the bug reporter send the patch to upstream MangoHud. It's not a huge change and I doubt they are gonna reject it.
See also bug 947057.
(In reply to Gonçalo Negrier Duarte from comment #3) > The original zenpower project is dead if look at the ebuild I using a fork > of the project. > For some reason that fork rename the sensor to zenstat instead of zenpower. > > So just send that patch upstream, me and Adel will not mantained it. Alright, being formal is going nowhere so now you get the Real Talk. There are thirteen zenpower forks currently on github; the other twelve do not break everything, the one you packaged has stayed dead after a single commit and its author has also made clear they're never returning to github. You have refused to justify your actions even after being shown how counterproductive and pointless they've been and I'm starting to wonder what the motivation behind them really is, because improving the software ain't it. I am not wasting my time signing up for Microsoft Github to bother projects about some libav-esque office-political rubbish I don't subscribe to; I'd get (justifiably) laughed out of the room for wasting *their* time asking for a hack for some rando's dead vanity project and the bug would remain not fixed. I have already done more than enough homework here as is by diagnosing, triaging, and providing a patch. This has been broken for over four months and you have been aware of that from the start and still refused to fix it. I am not taking the fall for such sloppy workmanship.
(In reply to Enne Eziarc from comment #2) > (In reply to Kostadin Shishmanov from comment #1) > > Make a PR upstream with the patch. > > No. It belongs in FILESDIR because it's a problem entirely caused by > downstream packaging. Explicitly stating that (and explaining it) in an annotation of the patch is appreciated in general.
(In reply to Kostadin Shishmanov from comment #5) > But why tho? The fork that is currently used also has support for AM5. Just > let the bug reporter send the patch to upstream MangoHud. It's not a huge > change and I doubt they are gonna reject it. I not really sure the commit really work I don't have AM5 machine to test. And there is a huge argument about the fork I use.
(In reply to Enne Eziarc from comment #7) > (In reply to Gonçalo Negrier Duarte from comment #3) > > The original zenpower project is dead if look at the ebuild I using a fork > > of the project. > > For some reason that fork rename the sensor to zenstat instead of zenpower. > > > > So just send that patch upstream, me and Adel will not mantained it. > > Alright, being formal is going nowhere so now you get the Real Talk. > > There are thirteen zenpower forks currently on github; the other twelve do > not break everything, the one you packaged has stayed dead after a single > commit and its author has also made clear they're never returning to github. > You have refused to justify your actions even after being shown how > counterproductive and pointless they've been and I'm starting to wonder what > the motivation behind them really is, because improving the software ain't > it. > Please leave the aspersions wrt motivation out of it. It's entirely reasonable to say the fork is a bad choice and we should really change (and that you're fed up), but just leave it at that.
I'm sorry if I'm missing it, but I can't spot what fork you're suggesting be used instead yet. Can you point it out?
(In reply to Sam James from comment #11) > I'm sorry if I'm missing it, but I can't spot what fork you're suggesting be > used instead yet. Can you point it out? The fork I gonna change is this one: https://github.com/koweda/zenpower3 The fork use in the ebuild, say it support AM5, but I really not sure if it work (since I don't have hardware to test) and commit doesn't seem ok, for example using zen2 and 1 calculation on zen5. I didn't change early because I forgot and that commit didn't have nothing nasty let say.
(In reply to Gonçalo Negrier Duarte from comment #12) > (In reply to Sam James from comment #11) > > I'm sorry if I'm missing it, but I can't spot what fork you're suggesting be > > used instead yet. Can you point it out? > > The fork I gonna change is this one: https://github.com/koweda/zenpower3 I also choose this fork because it solve some bug of the old ocerman one.
Sam do you know what's the current official way to get energy/power readings ? I even downloaded Phoronix's test suite and it seems to actually use zenpower (if my memory didn't get corrupted). I've never looked deep into RAPL otherwise. But it's weird that we're in zen5 already and AMD still doesn't provide an easy ootb way to get those readings...
No, I'm sort of baffled by it myself -- the zen CPUs are really popular and I can't understand how we're in this state of affairs, to the extent that I'm sure I'm missing something.
Sam James: you agree with the change?
I'd like to hear from OP first as to what their recommendation is, as they seem to have one but I've missed it.
(In reply to Adel KARA SLIMANE from comment #14) > I even downloaded Phoronix's test suite and it seems to actually use > zenpower (if my memory didn't get corrupted). I've never looked deep into > RAPL otherwise. > Yes it uses zenpower for the cpu power: https://github.com/phoronix-test-suite/phoronix-test-suite/blob/e1fdc09426136035743b509a6f963a237324ffd2/pts-core/objects/phodevi/sensors/cpu_power.php#L191C6-L191C7
