![]() * This is not macOS running exclusively on a limited, well-known set of Apple hardware. 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. KSysGuard and KDE System Monitor are system utilities, and as such should first and foremost display system information as it is. 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. 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. > 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. ![]() (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.)Īmdgpu: 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. ![]() 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). My usecases for all of the filtered drivers:Ĭoretemp: Similarly to what Artem mentioned, I'm interested in package temperature, not per-core temperatures.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |