Bug 445917

Thanks,  as I said there is not intentional filtering going on on the gpu sensors. There is though for CPU sensors, let's have this one for cpu sensors I will create a new issue for gpu sensors (done: 445920)

(In reply to David Redondo from comment #1)
> Thanks,  as I said there is not intentional filtering going on on the gpu
> sensors. There is though for CPU sensors, let's have this one for cpu
> sensors I will create a new issue for gpu sensors (done: 445920)

Alright... i personally don't use the cpu sensors currently with systemmonitor as there is the thermal monitor plasmoid, but here's the sensors -u output for k10temp, just in case ;)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:
  temp1_input: 53.625
Tccd1:
  temp3_input: 49.000

I just noticed that i don't have my mainboard-sensors in lm-sensors on this install (and don't want to search for sensors due to https://gitlab.freedesktop.org/drm/amd/-/issues/1470 for the time being), so the part about the mainboard sensors might be obsolete. I think i recall them missing, too, but i'm not 100% sure and it was still 5.22 i think.

Can we not remove the filter and just add labels to show that these redundant CPU sensors are from another plugin?

k10temp doesn't display per core temps, so technically it's not even redundant.

I have a Ryzen 9 5900X and it's really annoying that I cannot get the overall CPU temp by looking at CCD1 and CCD2. I prefer to put my CPU temp monitor as a widget in my panel as I do overclocking and want to quickly get a feel of the temp behavior with different settings. Without CCD1 and CCD2 temps, I am forced to pick one particular core out of 24(!) and I know that's not a good representation especially when I run single threaded applications.

*** Bug 454867 has been marked as a duplicate of this bug. ***

Due to this "filtering", it is now simply impossible to monitor CPU temperature
on the AMD FX series or processors. Can that filtering please be ripped out?

This also affects Intel CPUs. KSysGuard fails to expose the Package id 0 temperature on Intel Xeon E5 2699v4.

These are the temps from sensors:

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +39.0°C  (high = +69.0°C, crit = +79.0°C)
Core 0:        +34.0°C  (high = +69.0°C, crit = +79.0°C)
Core 1:        +33.0°C  (high = +69.0°C, crit = +79.0°C)
Core 2:        +34.0°C  (high = +69.0°C, crit = +79.0°C)
Core 3:        +34.0°C  (high = +69.0°C, crit = +79.0°C)
Core 4:        +34.0°C  (high = +69.0°C, crit = +79.0°C)
Core 5:        +32.0°C  (high = +69.0°C, crit = +79.0°C)
Core 8:        +34.0°C  (high = +69.0°C, crit = +79.0°C)


They correspond to:

/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp1_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp3_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp4_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp5_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp6_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp7_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp10_input

Please notice that the package temp is quite higher here than the other core temps, which makes it all the more important, but KSysGuard fails to show it.

There are two ways of solving these kind of bugs. One way, the one taken so far by KSysGuard devs, is to filter out some sensor plugins like coretemp from the Hardware Sensors thus trying to avoid exposing duplicate sensors, so as not to confuse the naïve user, at the expense of bumming out savvy users when KSysGuard cannot show some perfectly working and important sensors like the one I showed above. If the KsysGuard devs had enough time to maintain such complex code in the codebase taking account of the myriad of special cases tracked in as many separate bug reports, they would keep everybody happy. It's debatable whether it's be a good design decision, but that's ok. See this comment from 2021-07-15 by David Redondo explaining this criterion, for example: https://bugs.kde.org/show_bug.cgi?id=438318#c6

But the fact of the matter is that it's now almost 4 (four!) years later now, and the KSysGuard devs haven't found the time to resolve these bugs in any reasonable or effective way. Which not necessarily means they are at fault, but for sure this way doesn't seem to be working for anybody, neither the devs nor the users.

Then there's the other way of solving this sort of issues, which has been already insisted on by several users (see https://bugs.kde.org/show_bug.cgi?id=438318#c13) but so far was avoided by the devs. Which would be to recognize that maintaining such complexity is too difficult with the available devs and resources, and to remove the plugin filtering from the Hardware Sensors, thus making sure every available sensor can be shown by KSysGuard at the risk of exposing some sensors in two different categories. This could surprise a naïve user, yes, but how many naïve users would be tinkering with displaying sensors? Wouln't most of them be already savvy enough to simply use only one of those duplicate sensors? Maybe, even, the filtering removal could be enabled by some "advanced" preference checkbox, if anybody insists.

So, will the devs finally remove that frustrating filter, which is just a one line patch and be done with all this, once and for all?(https://invent.kde.org/plasma/ksystemstats/-/blob/15a03830/plugins/lmsensors/lmsensors.cpp#L24)

Pretty please??

A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksystemstats/-/merge_requests/113

This is now doubly unfortunate since Info Center started showing sensor data:
https://kde.org/announcements/plasma/6/6.4.0/
> And finally, a new Sensors page in Info Center shows raw sensor data for things like the temperature of your CPUs and GPUs.
https://kde.org/announcements/plasma/6/6.4.0/Sensors.png

So we have the sensors in Info Center, but not in System Monitor… imo this is even more confusing to the user than whatever the blacklist was supposed to prevent.

I went ahead and created a merge request, hopefully it can be accepted:
https://invent.kde.org/plasma/ksystemstats/-/merge_requests/113