Safety note: do not write arbitrary values to hardware-control files, unload vendor drivers, or disable thermal safeguards to force a fan setting. If your hardware path is unsupported, use monitoring-only behavior.

1. Record the environment

Collect your distribution and release, kernel version, CPU/laptop/motherboard model, firmware version and relevant driver information. These details are more useful than reporting only that “fan control does not work.”

2. Check what the system actually exposes

Linux sensor interfaces vary by driver and hardware. A fan reading or PWM control node may not exist for your system, may be firmware-managed, or may be intentionally read-only. Absence of a writable control interface should not be worked around by writing to unrelated paths.

3. Look for conflicting controllers

Vendor utilities, firmware services and third-party fan tools may compete for control. Identify the current controller before enabling another application. Avoid running two control loops against the same device.

4. Keep privileges narrow

Grant only the permissions required by the documented backend. Do not run the entire desktop UI as root simply because a hardware interface requires elevated access. Prefer a narrowly scoped, documented service or supported OS mechanism.

5. File a reproducible report

Include the exact distribution/kernel, device model, driver, app version, detected capability state and sanitized logs. Explain whether monitoring works while control is unavailable.

For HWcontrol2.0, see the getting-started guide, platform targets and issue reporting page.