Your fan runs at one speed, the function keys do nothing, and the battery charge limit option is missing. Then you read that platform driver improvements are queuing for the next kernel and wonder whether your machine is on the list. This guide shows you how to find out for yourself instead of guessing.
Phoronix reported that many laptop and gaming handheld support improvements are coming for Linux 7.4. This guide does not repeat that list, and it makes no claim about which devices or drivers land in 7.4. Read the Phoronix article for the actual device list. Check kernel.org and Phoronix for the merge window and release dates, because those dates can slip.
Testing note: every command below is untested, so read the output on your own machine before acting on it. The inspection commands are read-only. The kernel install and removal commands change your system, so back up first.
Prerequisites
You need a working install of a mainstream distro (Ubuntu, Debian, Fedora, Arch or a derivative), sudo access, and a way to reach the GRUB menu at boot. Check your release first.
## UNTESTED
cat /etc/os-release
Expect a NAME and VERSION_ID line. Note them, because the kernel upgrade options differ by distro. Immutable or gaming-focused distros (SteamOS-style or image-based systems) update the kernel through their own channel, so the manual install steps later do not apply there.
Step 1: Identify your exact hardware
Platform drivers match machines by DMI strings, the identifiers your firmware reports. A driver patch will usually name a product string like the ones you are about to read, so record them exactly.
## UNTESTED
cat /sys/class/dmi/id/sys_vendor
cat /sys/class/dmi/id/product_name
cat /sys/class/dmi/id/product_version
cat /sys/class/dmi/id/board_name
cat /sys/class/dmi/id/bios_version
Expect short strings: a vendor name, a model or product code, a board name and a BIOS version. Lenovo often puts the marketing name in product_version and a machine-type code in product_name, so record both.
If you prefer one command, sudo dmidecode -t system (also untested) prints the same data. It also prints a serial number, which you should not paste into public forums.
Step 2: Check your running kernel
## UNTESTED
uname -r
Expect a version string such as a major.minor number followed by distro-specific suffixes. The first two numbers matter most. If your kernel is older than the one you are hoping for, a newer driver cannot help until you move to that kernel or your distro backports the change.
Distro kernels complicate this. Ubuntu, Debian and Fedora sometimes backport individual patches, so a version number alone does not prove a feature is missing. Use the version as a first filter, then check the driver itself in the next step.
Step 3: See which platform drivers are loaded
You want to know whether a vendor driver is attached to your hardware at all. Start with a loose filter on loaded modules. This pairs well with see also: fix ea app games on linux: switch proton versions in steam.
## UNTESTED
lsmod | grep -Ei 'wmi|asus|lenovo|ideapad|thinkpad|legion|hp_|dell|msi|acer|samsung|platform_profile'
Expect lines showing a vendor WMI module with a size and a use count. An empty result does not always mean failure. The driver may be built into the kernel, or no driver may match your model yet. Check the module details and kernel messages next.
## UNTESTED
modinfo asus_wmi | head
sudo dmesg | grep -Ei 'wmi|acpi.*error|platform|legion|asus|ideapad|thinkpad'
Replace asus_wmi with the module you found. modinfo prints the file path, description and aliases. In dmesg, look for probe failures, unknown WMI GUIDs or ACPI errors. These hint that the firmware exposes something the driver does not understand yet. They do not prove a patch is missing, but they give you search terms.
Check which features the kernel actually exposes
A loaded driver does not mean working hardware. Look at the interfaces the common features use.
## UNTESTED
ls /sys/class/power_supply/
ls /sys/class/power_supply/BAT0/ | grep -i threshold
cat /sys/firmware/acpi/platform_profile
for f in /sys/class/hwmon/hwmon*/name; do echo "$f: $(cat $f)"; done
ls /sys/class/leds/
Battery limits normally show up as a charge threshold file. Power modes appear as a platform profile. Fan sensors appear as hwmon entries, and keyboard backlights or RGB zones appear under leds.
If the file for your broken feature does not exist, the kernel does not expose it, and a driver update is a plausible fix. If the file exists but the feature fails, the problem may sit in userspace or firmware instead.
Step 4: Search for work queued for your model
Now check whether anyone has written code for your machine. These sources are the primary ones.
- Search the mailing list archive. Open lore.kernel.org/platform-driver-x86 and search for your product_name, board_name, or the driver name. Patch subjects usually start with the driver prefix, for example "platform/x86: asus-wmi".
- Search the maintainers' tree. The platform-drivers-x86 repository on kernel.org holds patches queued for the next merge window. Browse its branches and log, or clone it and search locally.
- Search the tree for your DMI string. A model often gains support through an entry in a DMI table inside an existing driver.
- Compare against Phoronix. Read the Phoronix article linked above for the curated list, then compare it with what you found in the first three items.
## UNTESTED
git clone --filter=blob:none https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
cd platform-drivers-x86
git branch -r
git grep -n 'YOUR_PRODUCT_NAME' origin/for-next -- drivers/platform/x86
Substitute your real string. Run git branch -r first and pick the branch that holds queued work. Branch names can change, and for-next is a common one, but verify it.
A hit in a dmi_system_id table means your model has an explicit entry. No hit means nothing in that branch names your machine, though a generic fix may still help you.
A patch on the mailing list is not necessarily an accepted patch. Look for reviewer replies and an "applied" notice, and confirm the merge window and release date at kernel.org and Phoronix. For more on this, see linux hot page promotion explained: where amd ibs fits: the details.
Step 5: Decide whether to wait, upgrade, or stay
| Option | Best when | Risks | |---|---|---| | Wait for the distro kernel | Your fix is minor, or you rely on the machine for work | Slowest path. Your distro may not ship the new kernel for months, or at all for your release | | Backports or newer packaged kernel | Your distro offers one (Debian backports, Fedora vanilla repos, Arch mainline packages) | Third-party DKMS modules (GPU, VM) may break. Fewer bug reports for your exact setup | | Manual mainline kernel | You can confirm a needed patch is in that exact build and you can recover from a bad boot | Often unsigned, so Secure Boot may refuse it. Suspend, GPU, and Wi-Fi regressions are possible. Little distro support | | Stay on current kernel | Everything important works and the gap is cosmetic | You keep the missing feature |
My rule of thumb is an inference, not a measured result: if you cannot name the patch that fixes your model, stay put or wait for the distro. A newer kernel only helps when it contains the specific change you need.
If you go ahead, try a packaged route first:
- Debian: enable the backports repository for your release, then run
sudo apt install -t CODENAME-backports linux-image-amd64. - Ubuntu: prebuilt builds are available from the Ubuntu mainline kernel archive, but they are unsupported.
- Fedora: read the Kernel Vanilla Repositories page.
- Arch: install the linux package, or an alternative such as linux-mainline from the AUR.
These commands are untested too. Before installing, keep your current kernel installed, and do not remove it until the new one proves stable.
Step 6: Verify the new kernel and driver
Reboot, then repeat the checks.
## UNTESTED
uname -r
lsmod | grep -Ei 'wmi|asus|lenovo|legion|platform_profile'
sudo dmesg | grep -Ei 'wmi|acpi.*error'
ls /sys/class/power_supply/BAT0/ | grep -i threshold
Expect uname -r to show the new version. Expect your driver to be loaded or built in, with fewer errors in dmesg than before.
Then test the actual feature. Set a charge limit, press the function keys, change the fan profile, and run a suspend and resume cycle. If the broken feature now works and nothing else regressed, you are done. If nothing changed, the fix is not in your build, so return to Step 4 and search again.
Also read: enable nvidia reflex in proton on linux: setup & checks
Roll back if something breaks
If the machine fails to boot or misbehaves, restart and open the GRUB menu. Hold Shift on BIOS systems, or tap Esc during boot on many UEFI systems. Choose "Advanced options" and pick the previous kernel entry. That is why you kept it.
Once you are booted into the old kernel, remove the new one so it does not become the default again. These commands are untested, and the package names are placeholders you must replace after listing what is installed.
## UNTESTED
## Debian/Ubuntu
dpkg -l 'linux-image*' | grep ^ii
sudo apt remove linux-image-NEWVERSION
sudo update-grub
## Fedora
rpm -q kernel-core
sudo dnf remove kernel-core-NEWVERSION
## Arch
sudo pacman -R linux-mainline linux-mainline-headers
sudo grub-mkconfig -o /boot/grub/grub.cfg
After removal, run uname -r again and confirm you are on the older kernel. Do not remove the kernel you are currently running.
What to expect next
Driver changes queued for a merge window land in a release candidate first, then in a stable release weeks later. Your distro takes longer still. Recheck the Phoronix article and the platform-drivers-x86 archive when the merge window opens, and confirm the real dates at kernel.org. Keep your notes from Steps 1 to 3, because they are the search terms you will need again at every kernel release.
