Skip to content

[FEATURE] sysmon: add a CPU frequency stat (GHz), present in v4 as showCpuFreq #3691

Description

@meltingbots

Submission checklist

  • I have searched existing issues and confirmed this has not been requested before.
  • I have checked existing pull requests for similar changes.

Feature type

UI / visual improvement

Feature summary

The system monitor widget has no stat for CPU clock speed. The allowed stat
values are:

  cpu_usage  cpu_temp  ram_pct  swap_pct
  disk_used  disk_used_pct  disk_free  disk_free_pct
  gpu_usage  gpu_temp  gpu_vram
  net_rx  net_tx

Asking for a frequency stat is rejected:

  $ noctalia config validate freq.toml
  WARN  widget.cpufreq.stat: "cpu_freq" is not one of the allowed values

v4 had this: the sysmon widget exposed a showCpuFreq toggle, labelled
"Display current CPU clock speed in GHz". CPU usage and temperature carried
over to v5 as cpu_usage and cpu_temp; the frequency did not.

Request: add a frequency stat (e.g. cpu_freq), so a type = "sysmon" widget
can display GHz alongside usage and temperature.

Version: 5.0.0-beta.6 (Fedora 44, Terra).

Motivation / use case

This is a migration regression, not a new feature: users who had showCpuFreq
enabled in v4 lose the readout on upgrade, with no in-app replacement.

The data is a single sysfs read, already in kHz:

  /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq  ->  1800000

Most of the surrounding work already exists. The system-monitor service has
polling intervals (cpu_poll_seconds), and every stat already gets
<stat>_activity_threshold and <stat>_critical_threshold plus the widget
rendering path. A frequency stat would reuse the CPU poll cycle it already runs.

Today the only way to get it back is a custom Luau plugin: type = "scripted"
and type = "plugin" are not configurable widget types, and type = "text"
takes static text only (command, exec, script and interval are all
rejected as unknown settings). That works, but it means shipping a plugin to
recover a stat the built-in widget used to have.

Open questions the implementation would need to settle: average across cores
vs. fastest core (a plugin can offer both, but a built-in probably wants one
default), and whether to read scaling_cur_freq or cpuinfo_cur_freq.

Proposed solution

Add the option

Alternatives considered

No response

References / related projects

No response

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions