I built a custom kernel specifically for AMD ThinkPads — detkernel

#1

Detcom

💬

I've been running AMD ThinkPads for a while and always felt like the stock kernel carries a lot of dead weight, like Intel CPU/GPU drivers, NVIDIA, Dell/HP/Asus vendor blobs, server SCSI controllers, legacy filesystems, ancient WiFi drivers from 2003. None of that belongs on a ThinkPad.

So I built detkernel (yeah, I know), a custom kernel that strips all of that out and keeps only what AMD ThinkPads actually need.

What's removed:
- Intel CPU/GPU (i915, xe, microcode)
- NVIDIA (nouveau)
- All non-ThinkPad vendor drivers (Dell, HP, Asus, Sony, Apple...)
- Server SCSI controllers (Adaptec, LSI, HP SmartArray...)
- Legacy WiFi (Prism, ZyDAS, old Ralink, IPW2100/2200...)
- Dead filesystems (ReiserFS, HFS, UFS, JFFS2...)
- Legacy network protocols (AppleTalk, ATM, X.25...)

What stays:
- Full AMD support (Zen1–Zen5, RDNA GPU, ACP audio, PMC, P-state)
- All ThinkPad WiFi chips (Intel AX, Qualcomm WCN, MediaTek MT7921/MT7925, Realtek RTW89)
- Realtek LAN (it's in every ThinkPad)
- HDA Realtek audio + USB audio
- ThinkPad ACPI, HID Lenovo
- KVM/AMD, VFIO

Two variants:
- `detkernel-universal` — x86-64-v3, works on all AMD ThinkPads (T495 and newer)
- `detkernel-zen5` — znver5, for Ryzen AI 300 series (T14 G5-G6, T16 G3, P14s G5-G6), includes 500Hz tick, BBRv3 TCP, NTSYNC for Wine/Proton

Distributed as UKI (.efi) for systemd-boot users — just drop it in /boot/EFI/Linux/ and reboot. vmlinuz + initramfs also available for GRUB/rEFInd.

Currently based on Linux 7.0.12-zen1.

GitHub:

https://github.com/Detcom-GH/detkernel

Looking for testers, especially on older models (T495, T14 G1-G2, L14/L15). Would love to hear how it runs on your machine.

15 Jun 2026 11:52

#2

AcornTickler

💬

While I like the premise, I don't think the advantages of running a stripped down kernel warrants the tedium necessary to do it. If it was simply a package that you could update with your package manager, then I guess it would be worth it.

15 Jun 2026 12:44

#3

tal

💬

I mean, the kernel is modular to address this. If you aren't using a given set of functionality, the code doesn't get loaded into memory. You can maybe shave a bit of disk space down, but aside from that...

And some stuff, like filesystems, really aren't hardware-specific.

15 Jun 2026 13:15

#4

just_another_person

💬

Yeah, this should just be a series of build arguments.

15 Jun 2026 13:49

#5

Sxan

💬

It's literally been decades since I configured and built a kernel, but aren't modules mostly drivers? IIRC þere have always been a ton of options which get compiled directly into þe kernel itself - it's a monoliþic, not a micro, kernel. Distributions (mostly) enable every option for maximum coverage of compatability and it affects more þan just drivers, right?

I really don't know if pruning down options saves a _substantial_ amount of space in þe core. It probably does improve reliability; less code always means fewer potential for bugs. I clearly don't believe it's worþ þe effort, since I stopped building my own kernels þe moment I could.

But maybe it's becoming worþ it, again? Þe past year or so, it feels as if þe kernel has become less stable.

15 Jun 2026 14:27

#6

supermarkus

💬

Sounds like something suited for Gentoo. Nobody's going to download binary kernel images from a random Github

15 Jun 2026 16:16