- Audience: Linux laptop users, students, and administrators on Rocky/RHEL Linux 9.x who have completed Parts 1–3 of this series
- Difficulty: Beginner–Intermediate
- Time: About 30–45 minutes hands-on
- Reboot: Not required for any check in this guide, unless a check reveals a BIOS or firmware update is still pending
- How to confirm battery health, TuneD profile, and Wi-Fi power saving are all correctly applied
- How to validate PowerTOP tunables and interpret discharge rate against expected ranges
- How to verify the Intel graphics stack, VA-API driver, and Firefox hardware decoding end to end
- How to calculate a final optimization score and understand what lowers it
- How to use a consolidated troubleshooting matrix that spans the entire series
- Rocky/RHEL Linux 9.x with an account that has
sudoaccess - A laptop running on battery power for the discharge-rate and runtime checks
- Completion of Part 1: Battery Life Optimization, Part 2: Intel VA-API & Firefox, and Part 3: PowerTOP Guide is strongly recommended
Introduction
Parts 1 through 3 of this series covered battery health and TuneD, Intel VA-API and Firefox hardware video decoding, and a deep dive into PowerTOP's tunables. Each article stood on its own as a tutorial. This final article is different: it is a validation guide, not a teaching guide. Its job is to confirm, check by check, that everything configured earlier is still active and working together in the same Rocky Linux 9.8 Xfce validation environment used throughout the series.
Rather than reading through explanations, work through this checklist from top to bottom, running each command against your own laptop and comparing the result to the expected output. By the end, the final scorecard turns a series of pass/fail checks into a single optimization score.
Who Should Use This Checklist
This guide is for anyone who has already applied some or all of the optimizations from Parts 1–3 and wants a single pass to confirm nothing has drifted, especially after a kernel update, a BIOS update, or a fresh Rocky Linux installation cloned from notes rather than a documented process. It is also useful as a periodic health check, since PowerTOP's runtime tunables reset on every reboot and are easy to forget about.
| Situation | How to use this checklist |
|---|---|
| Just finished Parts 1–3 for the first time | Work through every section in order as a full validation pass |
| Returning after a kernel or BIOS update | Focus on the PowerTOP, TuneD, and graphics sections, since these are most likely to reset |
| Battery life suddenly feels worse | Start with Battery Health Validation and Power Consumption Validation |
| Video playback feels sluggish or hot | Jump to Intel Graphics, VA-API, and Firefox Hardware Acceleration Verification |
System Information
Confirm the checklist is being run against the expected system before validating anything else.
hostnamectl
cat /etc/rocky-releaseWhat it does: Reports the OS version, kernel, and hardware architecture. Expected output: Rocky Linux 9.x and a recent kernel version. Reboot required: No. Risk: None — this is a read-only check.
| Component | Validation environment |
|---|---|
| Laptop | Intel Ice Lake laptop |
| CPU | Intel Core i3-1005G1 (10th Gen Ice Lake) |
| Graphics | Intel UHD / Iris Plus G1 |
| OS | Rocky Linux 9.8, Xfce desktop |
| Browser | Firefox ESR 140 |
Hardware checklist
✓ Battery is the correct, healthy replacement or original unit
✓ Charger is the original or a compatible equivalent
✓ Cooling vents and fans are clean
✓ Thermal paste is fresh, particularly on laptops more than two or three years old
✓ SSD or NVMe health has been checked
✓ BIOS/firmware is reasonably current
Battery Health Validation
This section confirms the work from Part 1.
upower -i $(upower -e | grep BAT)What it does: Queries UPower for battery vendor, capacity, and current energy statistics. Expected output: Capacity close to 100% on a healthy or new battery, with Energy Full close to Energy Full Design. Reboot required: No. Risk: None.
| Field | What to check |
|---|---|
| Capacity | Above roughly 80% indicates a still-healthy battery; steadily declining values over months indicate normal wear |
| Energy Rate | Should roughly match the discharge-rate ranges recorded during PowerTOP validation |
| State | Reads discharging on battery or charging/fully-charged when plugged in |
✓ Battery health checked with upower
✓ Capacity verified against original design capacity
✓ Discharge rate at idle falls within the acceptable range for your hardware
TuneD Verification
tuned-adm active
tuned-adm profileWhat it does: Confirms the active TuneD profile and lists all available profiles. Expected output: Current active profile: balanced-battery (or whichever profile was selected in Part 1). Reboot required: No. Risk: None — read-only.
systemctl is-enabled tunedWhat it does: Confirms the tuned service starts automatically at boot. Expected output: enabled. Reboot required: No, but a reboot is a good way to confirm the profile survives a restart. Risk: None.
✓ balanced-battery (or chosen profile) is active
✓ TuneD service is enabled at boot
✓ Profile survived the most recent reboot
Wi-Fi Power Saving
iw dev wlo1 get power_saveWhat it does: Reports whether the wireless adapter's power-saving mode is enabled. Expected output: Power save: on. Replace wlo1 with your own interface name if different. Reboot required: No. Risk: Low — a small number of adapters behave unreliably with power saving on; if connections drop, disable it and retest.
✓ Wi-Fi interface name identified correctly
✓ Power save reports on
✓ No dropped-connection issues observed since enabling it
PowerTOP Verification
This section confirms the work from Part 3. Remember that auto-tune only applies for the current boot session.
rpm -q powertopWhat it does: Confirms PowerTOP is installed. Expected output: Package name and version. Reboot required: No. Risk: None.
sudo powertop --calibrateWhat it does: Runs PowerTOP's calibration sequence while on battery power. Expected output: Completes without errors. Reboot required: No. Risk: None, but must be run on battery power to produce meaningful results.
sudo powertop --auto-tuneWhat it does: Re-applies runtime power-saving tunables for the current session. Expected output: Most or all items on the Tunables tab report Good when PowerTOP is reopened. Reboot required: No — but this must be re-run after every reboot unless it has been automated. Risk: Low to medium; a small number of older USB peripherals may misbehave with autosuspend applied.
| Tunable | Expected state after auto-tune |
|---|---|
| USB autosuspend | Good, unless disabled for a specific incompatible device |
| SATA link power management | Good on systems with SATA storage |
| Runtime PM for PCI devices | Good for most Intel network, storage, and graphics components |
| Audio codec power management | Good |
| Bluetooth power management | Good, or Bluetooth disabled entirely if unused |
✓ PowerTOP installed
✓ Calibrated successfully on battery power
✓ --auto-tune reviewed and re-applied for this session
✓ Tunables list mostly or entirely Good
✓ Idle wakeups per second are in a reasonable range, with no single unexplained top contributor
CPU Frequency Verification
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorWhat it does: Reports the active CPU frequency scaling governor. Expected output: A governor consistent with the active TuneD profile, typically powersave or schedutil under balanced-battery. Reboot required: No. Risk: None.
✓ Scaling governor matches the expectations of the active TuneD profile
✓ CPU does not remain pinned at maximum frequency during idle or light workloads
Intel Graphics Verification
glxinfo -B
lspci -k | grep -A3 VGAWhat it does: Confirms OpenGL direct rendering and the active kernel graphics driver. Expected output: direct rendering: Yes, an Intel renderer string, and Kernel driver in use: i915. Reboot required: No. Risk: None.
✓ OpenGL acceleration confirmed working
✓ i915 kernel driver active
VA-API Verification
This section confirms the work from Part 2.
ls -l /usr/lib64/dri/iHD_drv_video.so
LIBVA_DRIVER_NAME=iHD vainfoWhat it does: Confirms the modern Intel Media Driver file is present and initializes correctly. Expected output: The file exists, and vainfo lists the Intel iHD driver along with supported codec profiles such as H.264, VP9, and HEVC, with no initialization errors. Reboot required: No. Risk: None — read-only check.
✓ intel-media-driver package installed
✓ iHD_drv_video.so present on disk
✓ vainfo completes successfully and lists expected codec profiles
Firefox Hardware Acceleration Verification
about:support
about:configWhat it does: Confirms Firefox reports hardware video decoding as available and the relevant preferences are enabled. Expected output: about:support shows Hardware Video Decoding: Available; about:config shows media.ffmpeg.vaapi.enabled, media.hardware-video-decoding.enabled, and media.rdd-ffmpeg.enabled all set to true. Reboot required: No, but Firefox must be restarted after changing any of these preferences. Risk: None.
| Check | Location | Expected value |
|---|---|---|
| Hardware Video Decoding | about:support |
Available |
media.ffmpeg.vaapi.enabled |
about:config |
true |
media.hardware-video-decoding.enabled |
about:config |
true |
media.rdd-ffmpeg.enabled |
about:config |
true |
| YouTube codec (Stats for Nerds) | Video player overlay | VP9 or H.264 preferred over AV1 on unsupported hardware |
✓ Hardware decoding enabled and reported Available
✓ about:config preferences verified
✓ Firefox restarted after any configuration change
✓ AV1 blocked via enhanced-h264ify if the GPU lacks AV1 decode support
Power Consumption Validation
With PowerTOP open on the Overview tab, record the discharge rate under a few representative workloads and compare against the reference ranges observed in the validation environment throughout this series.
| Workload | Reference discharge rate | Interpretation if significantly higher |
|---|---|---|
| Idle | 5–6 W | Check for unexpected wakeups, a Bad tunable, or a wrong TuneD profile |
| Web browsing | 7–9 W | Check open tab count and background extensions |
| 1080p video streaming | 8–12 W | Check whether hardware decoding is actually active for the codec being played |
| Heavy workloads (compiling, multitasking) | 15 W+ | Expected under load; only investigate if it persists after the workload ends |
✓ Discharge rate measured for at least idle and one active workload
✓ Values fall within, or reasonably close to, the expected ranges for comparable hardware
Battery Runtime Validation
upower -i $(upower -e | grep BAT) | grep -E "time to|percentage"What it does: Reports the current estimated time remaining and battery percentage. Expected output: A time to empty estimate consistent with the current discharge rate and remaining capacity. Reboot required: No. Risk: None.
✓ Runtime estimate reviewed and roughly consistent with discharge rate
✓ Runtime compared across at least two similar sessions rather than judged from a single reading
Common Mistakes
A few mistakes account for most of the confusion when working back through this checklist:
- Running TLP and TuneD together, which can cause the two frameworks to fight over the same settings.
- Assuming
powertop --auto-tunepersists after a reboot, when it only applies to the current session. - Judging battery health from percentage alone instead of comparing
Energy FullagainstEnergy Full Design. - Testing discharge rate while plugged in, which reports charging behavior instead of real discharge.
- Assuming a passing
vainforesult means Firefox is using hardware decoding, without also checkingabout:config. - Expecting identical battery life to Windows without accounting for firmware- and driver-level differences.
Final Optimization Score
Score each category based on how many checks in that section passed, then average them for an overall score. In the validation environment after completing all three earlier articles, the result looked like this:
| Category | Rating | Notes |
|---|---|---|
| Battery Health | ★★★★★ | Capacity at 100% on the replacement battery, discharge rate within range |
| TuneD | ★★★★★ | balanced-battery active and enabled at boot |
| PowerTOP | ★★★★☆ | All tunables Good after auto-tune; one point held back since it must be reapplied each boot |
| Graphics & VA-API | ★★★★★ | i915 and iHD both verified with vainfo passing |
| Firefox Hardware Acceleration | ★★★★★ | Hardware decoding available, VP9/H.264 preferred over AV1 |
| Overall | 96% | Well-optimized; the only recurring gap is PowerTOP's session-only tunables |
A score in this range represents a fully validated system rather than a perfect, unattainable one. Common reasons a score falls below 100% include a PowerTOP tunable that resets after reboot and has not yet been automated, an older USB peripheral that cannot tolerate autosuspend, occasional AV1 content falling back to software decoding, or a BIOS update that has not yet been applied. None of these individually indicate a broken configuration — they simply show where to focus the next pass through this checklist.
- This checklist validates the work from Parts 1–3; it does not replace them.
- PowerTOP's tunables are session-only and are the most common source of score drift between checks.
- A passing
vainforesult confirms the system-level driver, but Firefox's ownabout:configflags must also be verified. - Discharge rate and runtime figures should be compared across similar workloads, not treated as fixed numbers.
- A score in the 90–100% range reflects a genuinely well-optimized laptop; minor, explainable gaps are normal.
Conclusion
This checklist ties together everything covered across the series: a healthy, correctly reported battery; a TuneD profile that matches the intended power/performance balance; PowerTOP tunables verified and understood rather than blindly applied; and a complete Intel VA-API and Firefox hardware decoding pipeline confirmed end to end. Individually, each of the earlier three articles solved one piece of the puzzle. Run together as a single pass, they confirm the whole system is working as intended.
Optimization is not a one-time task. Kernel updates, BIOS changes, and new hardware can all shift individual results even after a laptop scores well on this checklist. Revisit this guide periodically, focus on whichever section a symptom points to, and rely on measured checks rather than assumptions — the same principle that ran through every part of this series.