Code for Linux 7.5 is already being staged, and the merge window that opens that cycle has not started. Phoronix reports that graphics and NPU driver changes have begun queuing up for it. That report has the specifics of what is queued. This article answers the question such headlines raise: when can you use the code on your machine?
What do drm-misc-next and drm-next actually mean?
They are staging branches in the kernel's graphics (DRM) subsystem. The drm-misc tree collects changes for the DRM core and for smaller drivers, and its drm-misc-next branch holds work intended for the next kernel cycle. Large drivers such as AMD's and Intel's keep their own staging trees, which feed the same pipeline.
Maintainers periodically send pull requests from those branches to drm-next. That tree is where all DRM work for a cycle comes together. During the merge window, the DRM maintainers send one big pull request from drm-next to Linus Torvalds, and the code enters mainline at that moment.
The branches stop accepting new feature work well before the merge window opens, so changes need to be staged early. That is why 7.5 material is queuing while the 7.5 merge window is still ahead. A change in drm-misc-next has been accepted for the next cycle, but it has not shipped. Developers can still rework, delay or revert it before Linus pulls it.
How many weeks pass from staging to a distro kernel?
The numbers below are typical, not guaranteed. Kernel cycles slip, distros skip releases, and individual patches get pushed back a cycle. Treat the durations as planning estimates.
| Step | What happens | Typical duration | |---|---|---| | 1. Staging | Change sits in drm-misc-next or a vendor tree, then moves to drm-next | Weeks to a couple of months, depending on when it was queued | | 2. Merge window | Linus pulls drm-next and other subsystems; rc1 is tagged at the end | About 2 weeks | | 3. Release candidates | rc1 through rc7 (sometimes rc8) stabilise the code | About 7 to 8 weeks | | 4. Final release | The new x.y.0 kernel is tagged; stable point releases follow | A full cycle is roughly 9 to 10 weeks from window to release | | 5. Distro packaging | Rolling distros pick it up; fixed-release distros wait for their own schedule | Days or weeks for rolling, months for fixed |
Here is an illustration. If the 7.5 merge window opens around the end of the year, as the staging news implies, a final 7.5 release would land roughly two to two and a half months later. That is an inference from the usual cycle length, not a published date. Add the distro step, and a feature staged today could reach a rolling-release desktop in early spring. A fixed-release desktop would get it well after that.
How do rolling, fixed-release and HWE or backports kernels differ?
Your distro's policy decides which kernel you run, not what Linus released. Rolling distros track upstream closely. Fixed-release distros freeze a kernel at release time and prefer stability. HWE and backports kernels are the compromise: an opt-in newer kernel for hardware that needs it. This pairs well with linux slab allocator explained: will 7.4 speed up your pc?.
| Distro type | Examples | Typical kernel lag | |---|---|---| | Rolling | Arch and Arch-based distros | Days to a few weeks after a stable release | | Fast fixed-release | Fedora | Usually a few weeks after release, delivered as a normal update | | Slow fixed-release | Debian stable, Ubuntu LTS default kernel | Months to years, with security and hardware fixes backported | | HWE or backports | Ubuntu HWE stack, Debian backports | Months after upstream; newer kernels arrive on the distro's own schedule |
Two caveats apply. Some Arch-derived distros, Manjaro among them, hold packages back for testing, so they lag a little behind pure Arch. Ubuntu's HWE kernels follow its point-release rhythm, so check the distro's documentation for the current schedule instead of assuming one.
How do I check my kernel and decide whether I need a newer one?
Start with uname -r. It prints your running kernel version, a major.minor number followed by distro-specific text. Then run cat /etc/os-release to confirm which distro and release you are on.
Next, check whether your hardware is bound to a driver. lspci -k lists PCI devices along with the kernel driver in use. A GPU with no driver, or a generic fallback, is a warning sign.
For NPUs, ls /dev/accel shows whether the kernel's accelerator subsystem has created a device node. If the node is missing, the driver may be absent, unsupported on your kernel, or missing firmware. sudo dmesg | grep -i firmware often shows load failures.
Then compare your kernel against the release that carries the feature. News reports or the commit history usually name the kernel release where a feature was merged. If your running kernel is older than that release, the feature is not in your kernel unless your distro backported it. Backports are recorded in the distro's kernel changelog or bug tracker. See close_range syscall explained: what sync closing changes: the details for additional background.
What should I do if I cannot wait?
Work through this checklist in order, and stop as soon as one step solves your problem.
- Run
uname -rand note your version. Find the kernel version that first carries the feature you want. - Decide whether the feature is a bug fix or new hardware enablement. Distros are more likely to backport fixes than new features.
- Update your system first. A routine update may already ship a newer kernel, especially on Fedora or Arch.
- On Ubuntu or Debian, look for an HWE or backports kernel package. On Debian, enable the backports repository for your release codename, then install the kernel with
apt install -t CODENAME-backports. Substitute your real codename. - Consider a mainline kernel build from a third-party repository only as a last resort. These builds are unsupported and can break out-of-tree modules such as proprietary drivers.
- Before rebooting, confirm the old kernel is still installed, and do not remove it. If the new kernel fails to boot or your display misbehaves, pick the old one from the advanced options entry in the boot menu.
- After booting, repeat
uname -r,lspci -kand the/dev/accelcheck. If the new kernel does not help, reboot into the old one and uninstall the newer package.
Also read: context: check cpu tlb size on linux: what the zen 5 fix changes
Package names vary by distro and release, so confirm these commands against your distro's documentation before running them.
If your hardware works today, skip all of this. Waiting for your distro's normal kernel is the right call when the staged change is a performance tweak, a cleanup or support for hardware you do not own.
Does "merged into the kernel" mean it will work on my machine?
No, and this is the most common misunderstanding. A kernel driver is only one piece. GPU features usually also need a matching Mesa release, and many AMD and Intel parts need up-to-date firmware from the linux-firmware package. NPUs often need a userspace runtime too, and news about the kernel side does not say when that part arrives.
A second trap is assuming backports will rescue you. Stable kernels mainly take bug fixes. Large new features seldom get backported into old kernels, and distros decide case by case. If a headline describes new feature work, plan on needing the kernel that carries it, plus the firmware and userspace that go with it.
