Created attachment 139133 [details]
screenshot 2

Same for CPU sensors: k10temp module provides Tctl, Tdie and Tccd1 temperatures, but System Monitor shows only a single "Core x Current Temperature" sensor.
Both k10temp and amdgpu are detected correctly under KSysGuard.

I can confirm this after updating to 5.22.1 (manjaro testing)

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

Found the same problem when upgrading to Plasma 5.22.3. The sensor coretemp-isa-0000 -> Package_id_0 (CPU temperature) has disappeared. There is no such sensor in any category of sensors in System Monitor now. The graph that used it is now empty. Now there is only the possibility of displaying the temperature of each processor core separately.
However, it is still available in KSysGuard:
Hardware Sensors -> coretemp-isa-0000 -> Package_id_0

Is there any way to modify the list of available sensors in System Monitor, or is there any way to get its old behavior back?

The cause of the problem is, that in the new sensors plugin coretemp, k10temp and amdgpu are intentionally excluded to not expose duplicated sensors because these are already handles by the CPU and GPU plugins. However those do not expose all of the available sensors.

For the amd gpu case it's possible to map gpu to sensors using the PCI address, so they can belong to GPU in the ui which makes more sense than in the hardware sensors dumping ground.

For coretemp, do you have a specific use case for monitoring the package temperature instead of for example core temps?

Well, I would like to have the correct information about the CPU temperature. The "sensors" command shows that the temperatures of the processor in general and specific cores in particular may differ, so using the temperature of a specific core is not a correct solution to the problem. The output of the temperature of all the cores in one chart will look very bulky and inconvenient for perception.

System Monitor already has a group of sensors "CPUs -> All", where there are sensors of the total CPU load. But why do they exist, if you can use the load of a specific core? (irony)

In my opinion, it would be quite consistent to add the value of the package  temperature to the "CPUs -> All" group.

My usecase is/was monitoring the GPU-Power - i guess the mentioned mapping of PCI-adresses is nothing that can be done in userspace but has to be patched in? Or am i missing something?

Thanks Artem, that's a good idea.

> PCI-adresses is nothing that can be done in userspace but has to be patched in? Or am i missing something?

Yes it has to be done in the code.
I mentioned it because I am currently working on it.

David Redondo, that is, can we expect that this will be fixed after some time? Should I start a separate issue on GitLab, or is it enough just to observe the current development?
I doubt that I will be able to implement such a change on my own, so I can only hope for you.

This bug report is sufficient to track the issue

My usecases for all of the filtered drivers:

coretemp: Similarly to what Artem mentioned, I'm interested in package temperature, not per-core temperatures.

k10temp: Ryzen CPUs have a peculiar way of reporting Tctl (search "Ryzen sawtooth"), and because of that I'd like to also monitor Tccd1 (which behaves much more reasonably).
(Also, k10temp only provides package temperatures, so it's a bit unintuitive when the CPU plugin splits it per-core, with all cores reporting the same temperature.)

amdgpu: This I think is the most clear, we're missing edge/junction/memory temperatures, fan speed, power, and voltage, and they are not available in any other way.

> The cause of the problem is, that in the new sensors plugin coretemp, k10temp and amdgpu are intentionally excluded to not expose duplicated sensors because these are already handles by the CPU and GPU plugins.
Is there any harm in having those sensors duplicated? Personally I think that CPU/GPU plugins could expose a vendor-neutral, standardized set of sensors, while Hardware Sensors could still expose raw, driver-specific sensor data. That way users could use sensors from CPU/GPU plugins for basic temperature/frequency/usage monitoring, while more demanding users could get all the data that the drivers provide.

(In reply to David Redondo from comment #6)
> The cause of the problem is, that in the new sensors plugin coretemp,
> k10temp and amdgpu are intentionally excluded to not expose duplicated
> sensors because these are already handles by the CPU and GPU plugins.
> However those do not expose all of the available sensors.

They should not be intentionally excluded, because CPU / GPU options are more limited than actual sensors. I.e. please let the user decide whether they are satisfied with more simplistic GPU / CPU option or have a need for detailed sensors. Taking away choice is a bad thing here.

To give another example. Imagine, tomorrow k10temp and amdgpu will add another metric. Since CPU / GPU UI doesn't anticipate it, it will be missing there until you implement it. While if you simply read all that sensors provide implicitly, it will become immediately available in the generic sensors section.

So the better approach is to simply not filter any existing sensors from it.

i agree that filtered choice as the only option isn't the best way to go - maybe add a checkbox "display raw sensor data" or something to still have the filtered few for less confusion for not-so-tech-savvy users.

Git commit ede1aab0d737e76a273f5c80606e86dd0df8603d by David Redondo.
Committed on 03/09/2021 at 11:30.
Pushed by davidre into branch 'master'.

Discover more hardware gpu sensors

Using the PCI address we can identify the sensors that belong
to the gpu and add them to the relevant SensorObject.
FIXED-IN:5.23

M  +27   -6    plugins/gpu/LinuxAmdGpu.cpp
M  +3    -0    plugins/gpu/LinuxAmdGpu.h

https://invent.kde.org/plasma/ksystemstats/commit/ede1aab0d737e76a273f5c80606e86dd0df8603d

Was this patch supposed to also make the power(watt) monitor/sensor available? If so, the bug should be reopened, as it seems to still be hidden.

I hold there still should be a way to add any kind of sensors, not filtering GPU ones out on purpose.

What about k10temp? I have a Pie Chart System Monitor Sensor in my bottom panel which used to display Tctl, until it unfortunately stopped working after an update. I left it there, hoping it would work again after another update, occasionally checking its settings. Now there's temperature for each core, but not for all cores (i.e. the CPU package temperature). I can add temperature for "[Group] CPU", which looks really fancy, but I already got an RGB keyboard, so I don't really need that. Will there be an option to just get a simple reading of the current CPU temperature again?

I can confirm that power consumption isn't being picked up from lm sensors for amdgpu.

Here is what I see when running sensors:

amdgpu-pci-0f00
Adapter: PCI adapter
vddgfx:        6.00 mV 
fan1:           0 RPM  (min =    0 RPM, max = 3300 RPM)
edge:         +51.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
junction:     +56.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
mem:          +56.0°C  (crit = +100.0°C, hyst = -273.1°C)
                       (emerg = +105.0°C)
power1:       37.00 W  (cap = 272.00 W)

I don't see power1 sensors in the GPU section in Plasma 5.23.1 monitor.

This approach with filtering is really not sustainable and will be broken every time something new is introduced.

Seriously, please allow users adding a generic sensor without any limitations if they want to.

For now I'm sticking to ksysguard which is not enforcing any pointless artificial limitations like that.

Exactly the same problem, I am missing the coretemp-isa-0000 sensor to measure the temperature of my entire Intel processor, not each core individually. I was hoping that with the release of Plasma 5.23 the problem will be solved, but this sensor is still unavailable.

Yeah i'd say it is definetely not resolved/fixed - there is still no sensor for gpu power and cpu temp. We have things like GPU mem clock or usage (that i think weren't there in the past), voltage and fan speed are re-added, but still not have the other sensors the bugreport was initially created for.

I heavily agree with shmerl that this filtering-approach isn't really a good idea, at least not as the only option...

I fully agree with the previous commenters that the filtering approach should not be the only option. I realize that it may be beginner-friendly, but speaking as someone coming from lm-sensors and simply looking for a way to graph its output, if it is not perfectly clear what sensor the GUI is actually using I'm just not going to use the GUI and will either continue running sensors in the terminal from time to time or end up hacking together some crappy custom plotter. I'm sure I'm not the only one feeling this way. I'm all for making KDE beginner-friendly, but it shouldn't be at the cost of advanced users. Perhaps there can be an option, off by default, to show all the sensors under "Hardware sensors" in addition to the filtered ones in CPU or something.

(In reply to Ilia Kats from comment #24)
> I'm all for making KDE beginner-friendly, but it shouldn't be at the cost of
> advanced users. Perhaps there can be an option, off by default, to show all
> the sensors under "Hardware sensors" in addition to the filtered ones in CPU
> or something.

Yes, good point. I'm using ksysguard because it allows selecting any available sensors exactly this way and you can see the sensor name.

KSysGuard and KDE System Monitor are system utilities, and as such should first and foremost display system information as it is. Any processing that helps to better dig through and display that information is a nice-to-have option, but should only be that - an option.

* This is not macOS running exclusively on a limited, well-known set of Apple hardware. Any attempt to properly clean up a raw list of sensors is futile.
* There's the kernel, lm_sensors, and systemd-sensorsd suddenly popping up wouldn't surprise me. That's the layer were cleanup should happen. Doing it at the application layer is conceptually wrong (but of course still a nice-to-have option, especially when the layers below leave something to be desired).
* There's a reason why people choose a particular OS and desktop environment. And sometimes that choice changes when beginners become experts. Don't look to macOS or Windows as if the grass was greener there, just because it's more polished. KDE is the side with the greenest grass.

I'll take a look into making a patch that simply removes this filtering.

Looks like the whole thing is built on top of libksysguard, so I need to figure out how to filters sensors from there to skip ones for CPU and GPU.

To clarify we do not skip any sensors for gpus anymore, all GPU sensors are exposed under GPU, closing this because of that.
As this bug is about GPU I am closing it, please file another bug for other actionable problems. 

If you want to take a look yourself the relevant code is not in libksysguard but ksystemstats repo

(In reply to David Redondo from comment #29)
> To clarify we do not skip any sensors for gpus anymore, all GPU sensors are
> exposed under GPU, closing this because of that.
> As this bug is about GPU I am closing it, please file another bug for other
> actionable problems. 
> 
> If you want to take a look yourself the relevant code is not in libksysguard
> but ksystemstats repo

i can't confirm that gpu power is exposed - could you elaborate?

The power1 sensor in the outputs? Let's create a new issue anyways since were we can collect relevant info since it's slightly different that it should be now there but isn't.

(In reply to David Redondo from comment #31)
> The power1 sensor in the outputs? Let's create a new issue anyways since
> were we can collect relevant info since it's slightly different that it
> should be now there but isn't.

I don't really see why it should be a new/differnt issue, but i've created https://bugs.kde.org/show_bug.cgi?id=445917 to follow up.

Created attachment 143878 [details]
Remove blacklist in lmsensors plugin

For anyone who just wants to get rid of filtering and use the hardware sensors directly, there is a simple blacklist in ksystemstats code:
https://invent.kde.org/plasma/ksystemstats/-/blob/15a03830/plugins/lmsensors/lmsensors.cpp#L24

Removing it makes the sensors correctly appear under Hardware Sensors category. I attached a patch that does just that.

(In reply to Maciej Stanczew from comment #33)
> For anyone who just wants to get rid of filtering and use the hardware
> sensors directly, there is a simple blacklist in ksystemstats code

Thanks!

(In reply to Maciej Stanczew from comment #33)
> there is a simple blacklist in ksystemstats code

It was so simple... I am ashamed that I could not find it myself.
Thank you, this workaround will help me wait for the official fix in greater comfort.

(In reply to Artem from comment #35)
> (In reply to Maciej Stanczew from comment #33)
> > there is a simple blacklist in ksystemstats code
> 
> It was so simple... I am ashamed that I could not find it myself.
> Thank you, this workaround will help me wait for the official fix in greater
> comfort.


Hi! how do you solve it? sorry for this, but I don't know how to remove the items from blacklist.. or I have to recompile something?
(I don't have AMD sensors on my laptop, intel and nvidia) KDE Neon 5.23.5
thanks!

(In reply to diminombre@gmail.com from comment #36)
> (In reply to Artem from comment #35)
> > (In reply to Maciej Stanczew from comment #33)
> > > there is a simple blacklist in ksystemstats code
> > 
> > It was so simple... I am ashamed that I could not find it myself.
> > Thank you, this workaround will help me wait for the official fix in greater
> > comfort.
> 
> 
> Hi! how do you solve it? sorry for this, but I don't know how to remove the
> items from blacklist.. or I have to recompile something?
> (I don't have AMD sensors on my laptop, intel and nvidia) KDE Neon 5.23.5
> thanks!

Hello!
1) You need to open the required branch of ksystemstats (in your case Plasma/5.23: https://invent.kde.org/plasma/ksystemstats/-/tree/Plasma/5.23), download its contents to your computer.
2) Automatically or manually apply the patch from comment #33 to the file ./plugins/lmsensors/lmsensors.cpp (comment or remove some lines).
3) In the root folder of the project run:
cmake ./
cmake --build ./
4) File ksystemstats_plugin_lmsensors.so will appear in the folder ./bin, it must be copied with a replacement to /usr/lib/qt/plugins/ksystemstats/ (this path is used by me, I am not sure that it is the same on all distributions) (you can backup old file).
5) After that, just restart System Monitor and all sensors should appear in the "Hardware sensors" category.

This fix is simple enough, but I have to repeat all this with some Plasma updates, which is a bit depressing.
This may not be the most proper way to do it, but it works for me.
And if this is not the place for such explanations, please, someone write me about it, so that I don't repeat this mistake in the future.

(In reply to Artem from comment #37)
> (In reply to diminombre@gmail.com from comment #36)
> > (In reply to Artem from comment #35)
> > > (In reply to Maciej Stanczew from comment #33)
> > > > there is a simple blacklist in ksystemstats code
> > > 
> > > It was so simple... I am ashamed that I could not find it myself.
> > > Thank you, this workaround will help me wait for the official fix in greater
> > > comfort.
> > 
> > 
> > Hi! how do you solve it? sorry for this, but I don't know how to remove the
> > items from blacklist.. or I have to recompile something?
> > (I don't have AMD sensors on my laptop, intel and nvidia) KDE Neon 5.23.5
> > thanks!
> 
> Hello!
> 1) You need to open the required branch of ksystemstats (in your case
> Plasma/5.23: https://invent.kde.org/plasma/ksystemstats/-/tree/Plasma/5.23),
> download its contents to your computer.
> 2) Automatically or manually apply the patch from comment #33 to the file
> ./plugins/lmsensors/lmsensors.cpp (comment or remove some lines).
> 3) In the root folder of the project run:
> cmake ./
> cmake --build ./
> 4) File ksystemstats_plugin_lmsensors.so will appear in the folder ./bin, it
> must be copied with a replacement to /usr/lib/qt/plugins/ksystemstats/ (this
> path is used by me, I am not sure that it is the same on all distributions)
> (you can backup old file).
> 5) After that, just restart System Monitor and all sensors should appear in
> the "Hardware sensors" category.
> 
> This fix is simple enough, but I have to repeat all this with some Plasma
> updates, which is a bit depressing.
> This may not be the most proper way to do it, but it works for me.
> And if this is not the place for such explanations, please, someone write me
> about it, so that I don't repeat this mistake in the future.

Thank you very much for you guide!! I will try it.

(In reply to Maciej Stanczew from comment #33)
> Created attachment 143878 [details]
> Remove blacklist in lmsensors plugin
> 
> For anyone who just wants to get rid of filtering and use the hardware
> sensors directly, there is a simple blacklist in ksystemstats code:
> https://invent.kde.org/plasma/ksystemstats/-/blob/15a03830/plugins/lmsensors/
> lmsensors.cpp#L24
> 
> Removing it makes the sensors correctly appear under Hardware Sensors
> category. I attached a patch that does just that.

Sweet, cheers for that.
Without this patch I can't get CPU temp at all (k10temp-pci-00c3). Temperatures reported per core are always 0°C

hi! i like to know, why this bug is marked as resolved if the problem still present?
thanks!

This is sensors output. The only way I can get CPU temp is k10temp-pci-00c3. Blacklisting it seems like an obvious bug to me.
I'm not sure what temperatures reported by it8720-isa-0228 are. One seems like temperature inside the case.

it8720-isa-0228
Adapter: ISA adapter
in0:         896.00 mV (min =  +0.00 V, max =  +4.08 V)
in1:           1.52 V  (min =  +0.00 V, max =  +4.08 V)
in2:           3.34 V  (min =  +0.00 V, max =  +4.08 V)
+5V:           2.99 V  (min =  +0.00 V, max =  +4.08 V)
in4:           3.02 V  (min =  +0.00 V, max =  +4.08 V)
in5:         832.00 mV (min =  +0.00 V, max =  +4.08 V)
in6:           3.34 V  (min =  +0.00 V, max =  +4.08 V)
5VSB:          2.98 V  (min =  +0.00 V, max =  +4.08 V)
Vbat:          3.10 V
fan1:         891 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
fan5:           0 RPM  (min =    0 RPM)
temp1:        +33.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +25.0°C  (low  = +127.0°C, high = +70.0°C)  sensor = thermal diode
temp3:        +81.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
cpu0_vid:    +1.250 V
intrusion0:  ALARM

k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +34.0°C  (high = +70.0°C)
                       (crit = +70.0°C, hyst = +68.0°C)

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:      868.00 mV
fan1:        1028 RPM  (min =    0 RPM, max = 3500 RPM)
edge:         +40.0°C  (crit = +97.0°C, hyst = -273.1°C)

Because the bug report was about amd gpu sensors missing which was fixed with the commit mentioned in comment #16

(In reply to David Redondo from comment #42)
> Because the bug report was about amd gpu sensors missing which was fixed
> with the commit mentioned in comment #16

It's not fixed for amdgpu either, as "power" still isn't available again...
And this confusion is an excellent example why i believe hardcoded black-/whitelisting isn't ideal, to put it diplomatic.

To make it clear there is no blacklisting of amdgpu sensors happening.  All reported sensors are added under "GPU" instead under the generic sensors one. If one is missing there is a bug somewhere that needs to be fixed. 

I am closing this bug since the original issue was fixed. If you have another bug such as a missing GPU sensor please file a new bug so we can act on it.  Like Matthias did with 445920.

(In reply to David Redondo from comment #44)
> I am closing this bug since the original issue was fixed. If you have
> another bug such as a missing GPU sensor please file a new bug so we can act
> on it.  Like Matthias did with 445920.

OK, I follow you suggestion, and I create the bug report: https://bugs.kde.org/show_bug.cgi?id=452782

(In reply to diminombre@gmail.com from comment #45)
> (In reply to David Redondo from comment #44)
> > I am closing this bug since the original issue was fixed. If you have
> > another bug such as a missing GPU sensor please file a new bug so we can act
> > on it.  Like Matthias did with 445920.
> 
> OK, I follow you suggestion, and I create the bug report:
> https://bugs.kde.org/show_bug.cgi?id=452782

Oh no, I followed the suggestion too and created my own bug https://bugs.kde.org/show_bug.cgi?id=452763

Thanks!

(In reply to Artem from comment #37)
> (In reply to diminombre@gmail.com from comment #36)
> > (In reply to Artem from comment #35)
> > > (In reply to Maciej Stanczew from comment #33)
> > > > there is a simple blacklist in ksystemstats code
> > > 
> > > It was so simple... I am ashamed that I could not find it myself.
> > > Thank you, this workaround will help me wait for the official fix in greater
> > > comfort.
> > 
> > 
> > Hi! how do you solve it? sorry for this, but I don't know how to remove the
> > items from blacklist.. or I have to recompile something?
> > (I don't have AMD sensors on my laptop, intel and nvidia) KDE Neon 5.23.5
> > thanks!
> 
> Hello!
> 1) You need to open the required branch of ksystemstats (in your case
> Plasma/5.23: https://invent.kde.org/plasma/ksystemstats/-/tree/Plasma/5.23),
> download its contents to your computer.
> 2) Automatically or manually apply the patch from comment #33 to the file
> ./plugins/lmsensors/lmsensors.cpp (comment or remove some lines).
> 3) In the root folder of the project run:
> cmake ./
> cmake --build ./
> 4) File ksystemstats_plugin_lmsensors.so will appear in the folder ./bin, it
> must be copied with a replacement to /usr/lib/qt/plugins/ksystemstats/ (this
> path is used by me, I am not sure that it is the same on all distributions)
> (you can backup old file).
> 5) After that, just restart System Monitor and all sensors should appear in
> the "Hardware sensors" category.
> 
> This fix is simple enough, but I have to repeat all this with some Plasma
> updates, which is a bit depressing.
> This may not be the most proper way to do it, but it works for me.
> And if this is not the place for such explanations, please, someone write me
> about it, so that I don't repeat this mistake in the future.

Hi,
I followed your list, even switch to exactly commit but I have got:

❯ cmake ./
fatal: HEAD does not point to a branch
-- Could NOT find KF5CoreAddons (missing: KF5CoreAddons_DIR)
-- Could NOT find KF5CoreAddons: found neither KF5CoreAddonsConfig.cmake nor kf5coreaddons-config.cmake
-- Could NOT find KF5DBusAddons (missing: KF5DBusAddons_DIR)
-- Could NOT find KF5DBusAddons: found neither KF5DBusAddonsConfig.cmake nor kf5dbusaddons-config.cmake
-- Could NOT find KF5Solid (missing: KF5Solid_DIR)
-- Could NOT find KF5Solid: found neither KF5SolidConfig.cmake nor kf5solid-config.cmake
-- Could NOT find KF5KIO (missing: KF5KIO_DIR)
-- Could NOT find KF5KIO: found neither KF5KIOConfig.cmake nor kf5kio-config.cmake
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find KF5 (missing: CoreAddons DBusAddons Solid KIO) (Required is
  at least version "5.86")
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/ECM/find-modules/FindKF5.cmake:93 (find_package_handle_standard_args)
  CMakeLists.txt:28 (find_package)

Successful help will be rewarded :)

The cpu temp is not shown in lmsensors plugin because it is in the CPU plugin as I said multiple times

Based on the usefull guide in the comment 37, im trying to cmake ./ version 5.24 but i have this error:

-- The following REQUIRED packages have not been found:

 * Sensors, <https://github.com/lm-sensors/lm-sensors>
   Used for reading hardware sensors that aren't covered by other plugins.
 * NL, <https://github.com/thom311/libnl/>
   Used for gathering socket info via the sock_diag netlink subsystem and for the network plugin when NetworkManagerQt is not available.

CMake Error at /usr/share/cmake-3.22/Modules/FeatureSummary.cmake:464 (message):
  feature_summary() Error: REQUIRED package(s) are missing, aborting CMake
  run.
Call Stack (most recent call first):
  CMakeLists.txt:84 (feature_summary)

The point is that lm-sensor is already installed and i can't install libnl... please i don't have any idea how to solve and without it my cpu sensor is broken...

> The point is that lm-sensor is already installed
Do you also have development headers installed?

> and i can't install libnl
Why?

It looks like you don't have your development environment set up correctly. I'd ask on the support channels of your distribution, they'll probably be able to provide better help, since the issue is not application-specific.