#Tag
Big news for Rockchip users: Upstream Linux now supports VDPU381 and VDPU383 hardware decode! This brings mainline H.264/HEVC acceleration, improved IOMMU-reset recovery, and new HEVC V4L2 controls that work with Vulkan Video! 🚀
Big news for Rockchip users: Upstream Linux now supports VDPU381 and VDPU383 hardware decode! This brings mainline H.264/HEVC acceleration, improved IOMMU-reset recovery, and new HEVC V4L2 controls that work with Vulkan Video! 🚀
The #LinuxKernel's up-to-date architectures (arm64, loongarch, powerpc, riscv, s390, x86) from now on only offer two preemption models: full and lazy.
This is due to the change "sched: Further restrict the preemption modes" (https://git.kernel.org/torvalds/c/7dadeaa6e851e7d67733f3e24fc53ee107781d0f); for more history on that, see also: https://lwn.net/Articles/994322/
That commit was merged a few hours ago as part of the the main scheduler updates (https://git.kernel.org/torvalds/c/36ae1c45b2cede43ab2fc679b450060bbf119f1b).
This also brought a few performance/scalability improvements as well as RSEQ based 'scheduler time slice extension' support. The latter allows a thread to request a time slice extension when it enters a critical section to avoid contention on a resource when the thread is scheduled out inside of the critical section. For more details on this, see https://lore.kernel.org/all/20251215155615.870031952@linutronix.de/ and https://lwn.net/Articles/1038235/
The #LinuxKernel's up-to-date architectures (arm64, loongarch, powerpc, riscv, s390, x86) from now on only offer two preemption models: full and lazy.
This is due to the change "sched: Further restrict the preemption modes" (https://git.kernel.org/torvalds/c/7dadeaa6e851e7d67733f3e24fc53ee107781d0f); for more history on that, see also: https://lwn.net/Articles/994322/
That commit was merged a few hours ago as part of the the main scheduler updates (https://git.kernel.org/torvalds/c/36ae1c45b2cede43ab2fc679b450060bbf119f1b).
This also brought a few performance/scalability improvements as well as RSEQ based 'scheduler time slice extension' support. The latter allows a thread to request a time slice extension when it enters a critical section to avoid contention on a resource when the thread is scheduled out inside of the critical section. For more details on this, see https://lore.kernel.org/all/20251215155615.870031952@linutronix.de/ and https://lwn.net/Articles/1038235/
The #Rust support in the #Linux #kernel is now officially a first class citizen and not considered experimental any more:
https://git.kernel.org/torvalds/c/9fa7153c31a3e5fe578b83d23bc9f185fde115da; for more details, see also: https://lwn.net/Articles/1050174/
This is one of the highlights from the main #RustLang for #LinuxKernel 7.0 that was merged a few hours ago ; for others, see https://git.kernel.org/torvalds/c/a9aabb3b839aba094ed80861054993785c61462c
The #Rust support in the #Linux #kernel is now officially a first class citizen and not considered experimental any more:
https://git.kernel.org/torvalds/c/9fa7153c31a3e5fe578b83d23bc9f185fde115da; for more details, see also: https://lwn.net/Articles/1050174/
This is one of the highlights from the main #RustLang for #LinuxKernel 7.0 that was merged a few hours ago ; for others, see https://git.kernel.org/torvalds/c/a9aabb3b839aba094ed80861054993785c61462c
What’s next for Tyr?
In a new @lwn subscriber-only article, Daniel Almeida explores a possible 2026 roadmap for upstreaming Tyr — a Rust driver for CSF-based Arm Mali GPUs — and shares his thoughts on the path forward.
What’s next for Tyr?
In a new @lwn subscriber-only article, Daniel Almeida explores a possible 2026 roadmap for upstreaming Tyr — a Rust driver for CSF-based Arm Mali GPUs — and shares his thoughts on the path forward.
Linux kernel framework for PCIe device emulation, in userspace
https://github.com/cakehonolulu/pciem
#HackerNews #LinuxKernel #PCIE #Emulation #Userspace #Technology #Development
Working on mainline Linux? 🤔
Upstream early for feedback, or wait until your code is fully polished?
Early upstream = faster feedback, early rework hints, collaboration from day one.
Waiting = fewer distractions for maintainers, cleaner mailing lists, less churn.
What’s your take? #LinuxKernel
The Linux kernel's Rust support has been officially approved, marking the end of its experimental phase and paving the way for broader memory-safe adoption. 🚀🐧💻 A game-changer for kernel stability! Details: https://www.heise.de/en/news/Linux-Kernel-Rust-Support-Officially-Approved-11109808.html #LinuxKernel #Rust #OpenSource #Newz
Linux Kernel Rust Code Sees Its First CVE Vulnerability
https://www.phoronix.com/news/First-Linux-Rust-CVE
#HackerNews #LinuxKernel #RustCVE #Vulnerability #CyberSecurity #OpenSource #TechNews
The Linux kernel's Rust support has been officially approved, marking the end of its experimental phase and paving the way for broader memory-safe adoption. 🚀🐧💻 A game-changer for kernel stability! Details: https://www.heise.de/en/news/Linux-Kernel-Rust-Support-Officially-Approved-11109808.html #LinuxKernel #Rust #OpenSource #Newz
The Input Stack on Linux – An End-To-End Architecture Overview
https://venam.net/blog/unix/2025/11/27/input_devices_linux.html
Patrick Louis writes: ""Let’s explore and deobfuscate the input stack on #Linux. Our aim is to understand its components and what each does. Input handling can be divided into two parts, separated by a common layer:
#Kernel-level handling: It deals with what happens in the kernel and how events are exposed to user-space
[…]
Exposed layer (middle)
[…]
User-space handling:
[…]
The Widgets, #XServer, #X11 window managers, and #Wayland compositors, which rely on everything else
We’ll try to make sense of all this, one thing at a time, with a logical and coherent approach.""
The Input Stack on Linux – An End-To-End Architecture Overview
https://venam.net/blog/unix/2025/11/27/input_devices_linux.html
Patrick Louis writes: ""Let’s explore and deobfuscate the input stack on #Linux. Our aim is to understand its components and what each does. Input handling can be divided into two parts, separated by a common layer:
#Kernel-level handling: It deals with what happens in the kernel and how events are exposed to user-space
[…]
Exposed layer (middle)
[…]
User-space handling:
[…]
The Widgets, #XServer, #X11 window managers, and #Wayland compositors, which rely on everything else
We’ll try to make sense of all this, one thing at a time, with a logical and coherent approach.""
Once again saw someone blaming the #rust support in the #Linux #kernel for their problems, when in fact the problem at hand had nothing at all to do with it[1].
Kinda funny but also quite worrying at the same time.
See the slightly edited screenshot from a chatroom message below for an example from today. If you look closer, you see that it is a segfault in a userspace #rustlang program.
[1] I once even saw someone complaining when the kernel in fact did not even have CONFIG_RUST enabled…
Once again saw someone blaming the #rust support in the #Linux #kernel for their problems, when in fact the problem at hand had nothing at all to do with it[1].
Kinda funny but also quite worrying at the same time.
See the slightly edited screenshot from a chatroom message below for an example from today. If you look closer, you see that it is a segfault in a userspace #rustlang program.
[1] I once even saw someone complaining when the kernel in fact did not even have CONFIG_RUST enabled…
Quick reminder on the likely reason why Valve's New Steam Machine only supports #HDMI 2.0:
""At this time an open source HDMI 2.1 implementation is not possible without running afoul of the HDMI Forum requirements.""
This is what Alex Deucher, the maintainer of the amdgpu #kernel driver, said one and a half years ago here:
https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_2303163
And from the ticket it looks like the problem remains.
See also Alex's earlier comment from early 2021 in the ticket:
https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_830547
""HDMI 2.1 is not available on #Linux due to the HDMI Forum.""
