The common thread this fortnight is tooling and turnaround — the parts of the stack that decide how fast you build, boot, and render. Yocto Project 5.2 “walnascar” is out, Linux 7.2-rc2 splits the long-monolithic device-ID headers to cut needless full-tree rebuilds, and a proposed DRM scheduler rework aims to stop compositors dropping frames when the CPU is loaded. On the hardware side, Raspberry Pi added a 10-inch Touch Display 2 at $80.
Yocto 5.2 “walnascar” released, the mod_devicetable header split lands in Linux 7.2-rc2, a proposed DRM scheduler rework to cut GPU submission latency, and a new 10-inch Raspberry Pi Touch Display 2 at $80.
Not every important update is a headline feature. This edition covers four developments that change day-to-day work for embedded teams: the tools you build with, the time your tree takes to rebuild, the smoothness of your on-device UI, and the panels you ship on. None of them is dramatic on its own, but together they shape build times, boot times, and product cost.
In this edition
- Yocto Project 5.2 “walnascar” is released. The new stable release of the reference embedded build system is out, with a tighter security default and toolchain updates (Yocto migration guide).
- Linux 7.2-rc2 splits the device-ID headers. The monolithic
mod_devicetable.his broken into per-subsystem headers to reduce full-tree recompiles (Phoronix, OSTechNix). - A DRM scheduler rework targets GPU submission latency. A proposal replaces workqueues with
kthread_workso a high-priority GPU client is not delayed by a busy CPU (Phoronix). - Raspberry Pi ships a 10-inch Touch Display 2. A 1200×1920 IPS panel with 10-point touch at $80 (Raspberry Pi).
Yocto Project 5.2 “walnascar” is released
The Yocto Project published release 5.2, codename walnascar, on 10 July 2026. This is the current stable release of the reference build system used to produce custom embedded Linux images.
Two changes are worth noting before you upgrade. The debug-tweaks image feature has been removed because its name hid what it actually did: it allowed the root user to log in with no password. If your local local.conf still carries EXTRA_IMAGE_FEATURES = "debug-tweaks", your build will now behave differently, and that is the correct outcome for anything close to production. Recipes that inherit cargo also no longer install libraries by default, which matters if you build Rust components.
The practical approach is to treat a Yocto version bump as a scheduled project, not a background update. Move one product line to walnascar on a branch, run a full clean build, and compare the image manifest and size against your current release before you migrate the fleet. Read the migration guide section by section — the OLDEST_KERNEL default and the removed image features are the kind of change that passes review quietly and then surprises you at first boot on hardware.
raghu@techveda.org:~$ git clone https://git.yoctoproject.org/poky
raghu@techveda.org:~$ cd poky
raghu@techveda.org:~$ git checkout walnascar
raghu@techveda.org:~$ git branch --show-current
walnascarIf you maintain your own BSP layer, check its compatibility line against the walnascar series and rebuild against it early. A layer that has not been updated for the new release is the most common cause of a build that fails only after you have committed to the upgrade.
Linux 7.2-rc2 splits the device-ID headers
Linux 7.2-rc2 was released on 5 July 2026, and development is on schedule for a stable 7.2 in late August or early September. One structural change in this cycle is a large refactor of the kernel’s device-ID headers: the long-monolithic include/linux/mod_devicetable.h has been broken up into smaller, per-subsystem headers, a change reported across the tree in more than a thousand files (Phoronix, OSTechNix).
The reason this matters is build time. That single header defined the match structures for almost every bus and subsystem, so touching one device ID could force a recompile of a large part of the tree. Splitting it means a change to, for example, a USB ID pulls in only the USB device-ID header, and unrelated subsystems no longer rebuild.
For anyone who compiles the kernel repeatedly — driver developers, BSP maintainers, CI pipelines — this reduces incremental build times, which is where most engineering hours actually go. The effect is invisible in a from-clean build and clear in the edit-compile-test loop.
There is a migration cost for out-of-tree drivers. If your driver includes mod_devicetable.h and relies on structures that now live in a per-subsystem header, you may need to adjust your includes when you rebase onto 7.2. Build your out-of-tree modules against a 7.2 release candidate now rather than discovering the missing include on the day you ship. Do not assume a specific new header path from second-hand coverage; confirm it against the 7.2 source tree when it lands.
A DRM scheduler rework targets GPU submission latency
Tvrtko Ursulin of Igalia sent a request-for-comments series that reworks the DRM GPU scheduler to lower job-submission latency when the system is loaded with many runnable processes (Phoronix, Igalia blog). The problem is that the scheduler currently pushes work through kernel workqueues, so when the CPU run queue is busy a high-priority graphics client can wait behind unrelated CPU work before its commands even reach the GPU.
The proposal replaces the workqueue path with kthread_work, dedicated kernel-thread execution, and the author reports a striking improvement, noting it is directly useful for preventing compositors from missing frames. This is a proposal under review, not a merged feature, so treat it as a direction rather than a shipped change.
For embedded teams this is more relevant than it looks. A product running a Wayland compositor on an SoC GPU — a kiosk, an instrument cluster, an industrial HMI — is exactly the case where a loaded CPU causes visible stutter in the UI. If you ship a graphics-driven interface, measure your frame pacing under deliberate CPU load today so you have a baseline, and follow this series; it points at the mechanism behind a class of stutter that is easy to blame on the GPU driver and hard to reproduce.
Raspberry Pi ships a 10-inch Touch Display 2
Raspberry Pi introduced a 10-inch model of its Touch Display 2 on 22 July 2026 at $80, alongside the existing smaller panels (Raspberry Pi, LinuxGizmos). The 10.1-inch IPS panel runs at 1200×1920, supports ten-point capacitive touch, is rated around 400 cd/m², and connects to the Raspberry Pi 5 and supported Compute Module carriers. The box includes the cables and mounting hardware.
The detail that affects design work is orientation: the panel is native portrait at 1200×1920. If your product is a landscape HMI you will drive it rotated, which means setting the display rotation in your compositor or kernel command line and checking that touch coordinates are transformed to match. A panel that shows the right image but reports touches from the wrong corner is a rotation-transform issue, not a hardware fault.
For product teams, an officially supported panel with documented Raspberry Pi integration lowers the risk that a third-party display carries — no guessing at a DSI timing table, no orphaned vendor patch to carry across kernel upgrades. At $80 with a Compute Module, this is a credible basis for a small production HMI, not only a bench toy. If you have been carrying a custom panel and a fragile out-of-tree display driver, this is worth a cost-and-maintenance comparison against your current bill of materials.
References
- Yocto Project 5.2 (walnascar) migration guide — docs.yoctoproject.org
- Yocto Project releases — yoctoproject.org
- Linux 7.2-rc2 released — Phoronix
- Linux 7.2-rc2: cleaning up the monster headers — OSTechNix
- DRM scheduler patches for lower job-submission latency — Phoronix
- Fair(er) DRM GPU scheduler — Igalia (Tvrtko Ursulin)
- A new 10-inch Raspberry Pi Touch Display 2 at $80 — Raspberry Pi
- Raspberry Pi launches 10-inch Touch Display 2 — LinuxGizmos
— Raghu Bharadwaj
