https://bugs.kde.org/show_bug.cgi?id=445917
Ariel <ariel122333444455555666...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ariel122333444455555666666@
| |gmail.com
--- Comment #6 from Ariel <ariel122333444455555666...@gmail.com> ---
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??
--
You are receiving this mail because:
You are watching all bug changes.
