Hardware Monitoring and Sensors

What is it?

Hardware monitoring reads the machine's own sensors: temperatures, fan speeds, voltages, the laptop lid, ambient light, accelerometers, chassis intrusion and headphone jacks. This roadmap plans one sensor class that every source registers with, so thermal policy, the shell and diagnostics can read any sensor without knowing its bus. Nothing in it has shipped; the only related code today is the ACPI embedded controller transport, and it stays switched off.

How does it work today?

The embedded controller, discovered but off. On laptops many sensors sit behind the ACPI embedded controller (EC). acpi_ec.c finds it through the ECDT table and implements the EC protocol: read, write, burst and query commands over its command and data ports (EC_CMD_READ 0x80 to EC_CMD_QUERY 0x84 in acpi_ec.h). It does not enable the EC, because doing so safely needs GPE acknowledgement and the ACPI Global Lock, and the boot log says so:

EC found (cmd=0x<port> data=0x<port> gpe=<n>) but NOT enabled: needs GPE acknowledgement and ACPI Global Lock arbitration

A machine without an ECDT logs no ECDT -- EC unavailable (namespace discovery not implemented). This driver belongs to the ACPI and Power Management roadmap.

No thermal readings. The local APIC's thermal interrupt entry exists but is masked (LAPIC_REG_LVT_THERMAL in lapic.c), and nothing reads ACPI thermal zones, battery status, the lid switch or CPU temperature registers. The roadmap text says ACPI power work "covers battery and thermal policy"; no such code exists yet.

How will it work?

A driver fills in a sensor_device_t and calls sensor_register(). Readers call sensor_read() for a typed reading (value, unit, scale, accuracy, update rate) or sensor_subscribe() for threshold and change events, published through the kernel notification facility and rate-limited so a noisy sensor cannot flood it. Backends for ACPI, SMBus and I2C chips and the EC all feed the same model, and important events (thermal throttling, fan faults, lid changes) go to the BlackBox timeline.

flowchart LR
    A[ACPI: thermal, lid, ALS] --> C[Sensor class]
    S[SMBus / I2C chips] --> C
    E[Embedded controller] --> C
    J[Audio jack detect] --> C
    C --> R[sensor_read]
    C --> N[Events: notification facility]
    N --> P[Thermal and shell policy]
    N --> B[BlackBox timeline]

What are its interfaces?

Shipped: the EC transport, acpi_ec_init(), acpi_ec_ready(), acpi_ec_discovered(), acpi_ec_read(), acpi_ec_write() and acpi_ec_read_block(). Planned: sensor_register(), sensor_read(), sensor_subscribe(), a sensors shell command, a Device Manager sensor tab and Registry mirrors of critical readings.

How do I use it?

There are no sensor readings to use yet. The EC parser and transport tests run in the boot suite (test_acpi_ec.c):

bash scripts/test.sh SUITE=boot

What is not implemented yet?

The sensor class (Sensor Class API).
Backends: ACPI Sensors, SMBus/I2C hwmon Transport (needs the I2C bus from I2C and Precision Touchpad).
Sensor types: Fan, Voltage, and Chassis Sensors, Accelerometer and Orientation Sensors, Audio Jack and Presence Sensors (needs Audio Drivers).
Delivery and diagnostics: Event Notifications, Diagnostics, BlackBox Timeline and Tests.
Enabling the EC itself, which is owned by the ACPI roadmap.

How does it compare with Windows 11 and Linux?

Windows 11 exposes sensors through the Sensor Class Extension and thermal data through ACPI and WMI. Linux has three families: hwmon for temperatures, fans and voltages, iio for accelerometers and light sensors, and input for switches such as the lid. Impossible OS plans one class for all of them, plus a BlackBox record of environmental events, and reads no sensors today.