DEV Community: Bharat Dev Burman

Beyond the Mute Button: How a Broken LED Led to My First Linux Mainline Kernel Commit

Bharat Dev Burman — Fri, 17 Jul 2026 19:41:20 +0000

Every Linux user has that one thing. That tiny, lingering hardware quirk that doesn’t break the OS, but softly mocks you from the keyboard every single day. For me, it was the hardware audio mute LED on my HP Victus laptop. When I muted the volume, the light refused to turn on. It was a purely cosmetic malfunction, but to a systems developer, a broken LED is an unresolved puzzle.

What started as a minor weekend irritation turned into a deep dive through the layers of Linux audio architecture, Secure Boot cryptography, and enterprise-grade security policies. Ultimately, it culminated in a native kernel patch accepted into the mainline Linux kernel in record time by one of the community's legendary maintainers.

Here is the story of my first upstream Linux kernel commit.

The Fragile Illusion of User-Space Fixes

Like anyone encountering a hardware quirk, I initially looked for a quick workaround. I found that a few users had written custom ACPI scripts using a tool called hda-verb to manually toggle the codec pins.

On paper, it worked. But in practice, it was a fragile illusion:

No State Persistence: The scripts didn't remember the last state across sleep cycles, reboots, or sudden audio source switches.
The Security Wall (Fedora vs. Ubuntu): The existing workarounds were tailored for Ubuntu-family distributions. Ubuntu utilizes AppArmor , which can be configured to let hda-verb execute via sudo without much friction. However, I run Fedora , which uses SELinux. SELinux treats user-space manipulation of low-level hardware audio codecs with extreme suspicion. Trying to safely bypass the SELinux nuances to let a user-space script poke at an ALSA audio codec was like trying to cut bread with a chainsaw—it was structurally unsafe and inherently flawed.

It became obvious: fixing this properly meant leaving user-space behind. The logic belonged exactly where hardware management is supposed to live: inside the Linux Kernel.

Diving Into the Kernel & Codec Architecture

I pulled the kernel source and began investigating the Realtek audio codec architecture (sound/pci/hda/patch_realtek.c). The goal was to write a native C patch that mapped the specific subsystem ID of my HP Victus laptop to the correct alc245 mute LED helper functions already present in the kernel's sound subsystem.

Instead of overriding policies or forcing permissions, a kernel-level implementation handles the LED state cleanly within the ALSA subsystem itself. Whenever the master playback volume is muted, the driver natively communicates with the Realtek codec to trigger the GPIO pin connected to the physical LED. No scripts, no extra processes, and no broken state loops.

The Secure Boot & `fedpkg` Gauntlet

Writing the C patch was only half the battle. To verify that this fix would behave flawlessly for an everyday Linux user, I had to test it under standard consumer conditions—which meant keeping Secure Boot enabled.

Modern Linux distributions protect the integrity of the kernel under Secure Boot by refusing to load unsigned custom modules or unverified kernel builds. To replicate a regular user environment without compromising security, I had to set up a full Machine Owner Key (MOK) infrastructure:

Generated a custom cryptographic MOK key pair.
Enrolled the MOK public key into the system's UEFI firmware via the custom blue MOK management screen upon reboot.
Configured the Fedora package build system (fedpkg) to compile a custom RPM package of the kernel.
Signed the resulting kernel build with my enrolled MOK key.

Seeing the custom kernel boot cleanly with Secure Boot active—and witnessing the mute LED light up natively for the very first time—was an incredibly satisfying milestone. The patch worked perfectly.

17 Hours: The Nuremberg Connection

With a clean, verified patch in hand, it was time to brave the strict etiquettes of the Linux Kernel Mailing List (LKML). I formatted the patch precisely according to kernel documentation, composed a concise commit message, and fired it off using git send-mail.

The email left my machine at around 12:13 AM IST.

The patch landed in the inbox of Takashi Iwai , the legendary maintainer of the Linux sound subsystem, located over in Nuremberg, Germany. I shut down my laptop expecting a long, agonizing wait filled with potential review iterations, formatting critiques, or silence. After all, kernel maintainers manage thousands of incoming patches alongside incredibly demanding schedules, and we both are humans who need sleep, food breaks, and time away from terminal screens.

What happened next blew my mind.

About 17 hours after I hit send, a notification popped up. Takashi Iwai had reviewed, verified, and accepted the patch with a wonderfully brief, classic kernel maintainer sign-off:

"Applied to for-next branch. Thanks.

Takashi"

A 17-hour turnaround from an absolute stranger (he isn't) across the globe, cutting through time zones, personal routines, and heavy maintainer queues to pull my code into the official subsystem branch.

The Mainline and Beyond

A few weeks later, the merge window opened, and the commit officially entered the mainline Linux kernel.

But the story didn't end there. Because the patch fixed a genuine hardware defect on widely distributed consumer hardware, Sasha Levin (another prominent kernel maintainer) picked it up and backported it into the active stable 6.x series kernel updates.

Today, anyone tracking the stable Linux kernel updates on an HP Victus laptop gets a working hardware mute LED completely out of the box—no custom scripts, no broken state, and no SELinux conflicts.

What I Learned

My first upstream commit taught me that the Linux kernel community, despite its intimidating reputation, is incredibly efficient when you respect the process, test rigorously against modern constraints (like Secure Boot), and solve structural problems at the right layer of the stack.

If there is a hardware bug bugging you today, don't just patch it in user-space. Dig into the source. The view from the mainline is entirely worth it.

Link to the commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72919c57a055f6d7b79d66731dc398e9b433f47c

Kotlin Multiplatform vs Flutter: Showdown time!

Bharat Dev Burman — Fri, 17 Jul 2026 19:18:01 +0000

In the ever-evolving landscape of cross-platform mobile development, two major contenders have emerged, each with a distinct philosophy: Kotlin Multiplatform (KMP) and Flutter. While both aim to solve the challenge of building applications for multiple platforms with a single codebase, they approach it from different angles, leading to a fascinating "showdown" in terms of features, performance, and development experience.

Let's dive into a head-to-head comparison to help you understand which technology might be the best fit for your next project.

Kotlin Multiplatform: Native Fidelity with Shared Logic

Kotlin Multiplatform, championed by JetBrains, takes a unique approach. Instead of providing its own rendering engine and UI framework, KMP focuses on sharing business logic, data models, networking, and other non-UI code across various platforms (Android, iOS, Web, Desktop). The key differentiator is that it allows for native UI development on each platform.

How it works:

You write your core application logic in Kotlin.
This shared Kotlin code is then compiled to native binaries for iOS (via Kotlin/Native) and JVM bytecode for Android.
For the UI, you leverage the native UI frameworks: Jetpack Compose for Android and SwiftUI/UIKit for iOS. With the advent of Compose Multiplatform, developers can now share UIs across platforms as well, bringing KMP closer to Flutter's full-stack cross-platform capabilities.

KMP Advantages:

Native Performance and Look & Feel: By utilizing native UI frameworks, KMP ensures that your application looks and feels truly native on each platform. This can lead to superior performance and a more seamless user experience, as it directly taps into the platform's rendering capabilities.
Maximum Flexibility: KMP offers granular control over what you share. You can share just a small piece of critical logic, an entire domain layer, or even the UI with Compose Multiplatform. This flexibility is invaluable for projects that need to maintain a highly customized native experience.
Seamless Integration with Existing Native Codebases: For projects with existing Android or iOS apps, KMP can be gradually adopted to share new features or specific modules, without requiring a complete rewrite. This "incremental adoption" is a significant benefit.
Access to Native APIs: KMP provides direct and easy access to all platform-specific APIs and libraries, allowing you to leverage the full power of each operating system.
Kotlin Ecosystem: Developers familiar with Kotlin for Android development will find KMP a natural extension of their skillset.

KMP Disadvantages:

Steeper Learning Curve for iOS Developers: While Android developers will find KMP familiar, iOS developers will need to learn Kotlin if they are working on the shared logic. For UI, they will still work with Swift/Objective-C and SwiftUI/UIKit.
Separate UI Development (Traditionally): Until recently, KMP primarily focused on shared logic, meaning you still had to write separate UIs for Android and iOS. While Compose Multiplatform addresses this, it's a newer addition and might require a learning curve for some.
Smaller Community and Library Ecosystem (Compared to Flutter): While growing rapidly, KMP's community and the number of ready-to-use third-party libraries are still smaller than Flutter's.

KMP Use Cases:

Applications where a native look and feel and maximum performance are paramount.
Projects that need to share complex business logic across platforms while retaining platform-specific UIs.
Existing native applications looking to gradually introduce cross-platform features without a full rewrite.
SDKs and libraries that need to be consumed by both Android and iOS applications.
Augmented Reality, IoT, Wearables, and automotive applications where deep native integration is often required.

Flutter: Unified UI and Rapid Development

Flutter, backed by Google, offers a complete cross-platform solution, including its own rendering engine (Skia) and a rich set of customizable widgets. Its philosophy is to write once, run anywhere, encompassing both business logic and UI.

How it works:

You write your entire application in Dart, a language optimized for client-side development.
Flutter's engine then compiles this Dart code into native ARM code for both Android and iOS, bypassing the need for a JavaScript bridge often found in other cross-platform frameworks.
The UI is built entirely with Flutter's own widgets, which are rendered directly by the Skia (and now Impeller) engine, ensuring consistency across platforms.

Flutter Advantages:

Single Codebase for UI and Logic: This is Flutter's biggest draw, significantly accelerating development and reducing maintenance overhead.
Fast Development with Hot Reload/Restart: Flutter's hot reload feature allows developers to see changes in real-time without losing the application's state, dramatically speeding up the iteration process.
Rich Widget Catalog and Expressive UI: Flutter provides a comprehensive and customizable set of widgets that can be combined to create beautiful and complex UIs. Its declarative UI approach is often praised for its simplicity and power.
Consistent UI Across Platforms: Because Flutter renders its own UI, you get pixel-perfect consistency across Android and iOS, which can be a double-edged sword (see disadvantages).
Strong Community and Ecosystem: Flutter boasts a large and active community, along with a vast array of third-party packages and libraries, making it easier to find solutions and support.
Excellent Documentation and Tooling: Google provides extensive documentation and robust development tools (like DevTools) for Flutter.

Flutter Disadvantages:

Larger App Size: Flutter apps tend to be larger in file size due to the inclusion of the Flutter engine and its widgets within the app bundle.
Non-Native Look and Feel (Potentially): While Flutter strives to mimic native components with its Material Design and Cupertino widgets, it's still a custom rendering. This can sometimes lead to a subtle difference from a truly native application, especially as platform design trends evolve.
Dart Language: While easy to learn, Dart is less widespread than Kotlin or Swift, which might present a learning curve for developers new to the language.
Limited Access to Deep Native Features (Comparatively): While Flutter provides plugins for accessing many native features, interacting with highly specific or bleeding-edge platform APIs might require writing custom platform channels.

Flutter Use Cases:

Applications prioritizing rapid development and a consistent UI across platforms.
Startups and small teams with limited resources who need to quickly launch an MVP on both Android and iOS.
Apps with custom UI designs that are not heavily reliant on strict native aesthetics.
Internal business applications or prototypes where time-to-market is critical.
Projects aiming for web and desktop support in addition to mobile.

The Showdown: Who Wins?

There's no single "winner" in the Kotlin Multiplatform vs. Flutter showdown. The best choice depends entirely on your project's specific needs, team expertise, and long-term goals.

Feature	Kotlin Multiplatform (KMP)	Flutter
Code Sharing	Logic-centric, with optional shared UI (Compose Multiplatform)	Full code sharing (UI and Logic)
UI Approach	Native UI (Jetpack Compose, SwiftUI/UIKit) or Shared UI (Compose Multiplatform)	Custom widget-based UI rendered by Skia
Performance	Potentially higher (closer to native)	Excellent, near-native performance
Look & Feel	Truly native (when using platform UIs)	Highly consistent, can mimic native but is custom-rendered
Development Speed	Fast for shared logic; UI still requires platform-specific knowledge (unless using Compose Multiplatform)	Very fast with hot reload and single codebase
Learning Curve	Easier for Android devs, more for iOS devs (for shared logic)	New language (Dart), but easy to pick up; consistent framework
Community/Ecosystem	Growing rapidly, but smaller than Flutter	Large, mature, and highly active
App Size	Generally smaller (especially with only shared logic)	Generally larger
Native API Access	Direct and seamless	Via plugins; custom platform channels for deeper access
Integration with Existing Apps	Excellent for incremental adoption	Possible, but can be more involved

Choose Kotlin Multiplatform if:

You prioritize native performance and a truly native user experience.
You have an existing native codebase and want to gradually introduce cross-platform modules.
Your team has strong Kotlin and native mobile development expertise.
Your application requires deep integration with platform-specific APIs and hardware.
You are building an SDK or library that needs to be consumed by both Android and iOS apps.

Choose Flutter if:

You need to develop a mobile application quickly and efficiently for both Android and iOS.
You want a single codebase for both UI and business logic, maximizing code reuse.
You prioritize consistent UI and branding across all platforms.
Your team is comfortable learning Dart or has existing Dart expertise.
You are building an MVP or a consumer-facing app where rapid iteration is key.

In conclusion, both Kotlin Multiplatform and Flutter are powerful tools for cross-platform development, each with its unique strengths. The "winner" in your specific scenario will be the one that best aligns with your project requirements, team capabilities, and strategic vision. The current trend suggests that while Flutter continues to dominate for full-stack cross-platform development, Kotlin Multiplatform, especially with Compose Multiplatform, is becoming an increasingly compelling option for those seeking the best of both native and cross-platform worlds.

Revolutionizing the Android Build: An In-Depth Look at the Soong Build System

Bharat Dev Burman — Thu, 05 Jun 2025 06:32:39 +0000

The Android Open Source Project (AOSP) is a massive undertaking, comprising millions of lines of code across various languages. Building such a complex system efficiently and reliably is a monumental task. For years, the Android build relied heavily on GNU Make, but with the increasing complexity and scale of the platform, a more modern, robust, and performant solution was needed. This led to the introduction of the Android Soong build system, a significant leap forward in how Android is compiled.

From Make to Soong: The Evolution of Android Builds

Prior to Android 7.0 (Nougat), the build process was primarily orchestrated by Android.mk files, which leveraged GNU Make. While Make was a staple for many years, its limitations became apparent as Android grew. Makefiles can become intricate and difficult to maintain, especially with conditional logic and complex dependencies. Incremental builds, crucial for developer productivity, were often unreliable, frequently necessitating a full rebuild to ensure correctness.

Soong was introduced to address these challenges, aiming to provide a faster, more declarative, and maintainable build experience. It doesn't entirely replace all existing tools but rather integrates with them to create a streamlined workflow. At its core, Soong leverages the Kati GNU Make clone tool (for legacy Android.mk files during the transition) and the highly efficient Ninja build system as its backend.

The Heart of Soong: Android.bp Files

The most visible change with Soong is the shift from Android.mk files to Android.bp files. These Android.bp files are declarative descriptions of "modules" to be built, similar in syntax and semantics to Bazel BUILD files. This declarative nature is a key advantage, making build configurations more readable and less prone to errors compared to the imperative style of Makefiles.

Here's what defines an Android.bp file:

Modules: The basic unit of building in Soong is a module. Each module starts with a module type (e.g., cc_binary, java_library, android_app) followed by a set of properties in a name: value format. Every module must have a unique name property.
Declarative Syntax: Android.bp files focus on what needs to be built and its dependencies, rather than how it should be built. The build logic itself is implemented in Go within Soong's internal components.
No Explicit If-Statements (mostly): Unlike Android.mk files that allowed complex conditional logic using ifeq, Android.bp files primarily rely on pre-defined distinctions like processor architecture or debug/release builds. Custom case distinctions are handled by the Go-based Soong modules themselves, promoting a cleaner and more structured build graph.
Globs and Variables: Android.bp supports glob patterns for file lists (e.g., src/**/*.java) and allows for top-level variable assignments, enhancing flexibility and reducing redundancy.
Comments: Both C-style /* */ and C++ style // comments are supported for better readability.

How Soong Works Under the Hood

The Soong build system operates in a multi-stage process:

Parsing Android.bp Files: Soong parses all Android.bp files across the AOSP tree. This involves reading the declarative module definitions and their properties.
Generating Ninja Build Files: Based on the parsed Android.bp files and the internal build logic (written in Go), Soong generates a highly optimized build.ninja file. Ninja is designed for speed and efficiency, particularly for incremental builds, by creating a precise dependency graph and executing build commands in parallel.
Kati for Legacy Android.mk: During the transition period, Kati acts as an intermediary, processing Android.mk files and generating additional .ninja files that integrate with the overall Ninja build graph. This allows for a gradual migration without requiring a complete rewrite of the entire AOSP at once.
Ninja Execution: Finally, the Ninja build system takes the generated .ninja files and executes the actual build commands, compiling source code, linking libraries, and creating the final Android images and artifacts.
soong_ui as the Orchestrator: The soong_ui script acts as the primary driver for the entire build process, orchestrating the different stages and managing auxiliary tools.

Advantages of the Soong Build System

The shift to Soong brings several significant advantages to Android platform development:

Improved Build Performance: By leveraging Ninja, Soong significantly speeds up build times, especially for incremental builds. This is crucial for developers who frequently make small changes and need quick feedback.
Enhanced Reliability of Incremental Builds: Soong's precise dependency tracking and Ninja's efficient execution minimize the need for full rebuilds, making incremental builds more reliable and consistent.
Declarative and Readable Configuration: Android.bp files offer a cleaner, more understandable syntax compared to complex Makefiles, reducing the learning curve for new developers and improving maintainability.
Stronger Type Checking: Soong's Go-based implementation allows for stronger type checking of variables and properties, catching errors earlier in the development cycle.
Better Scalability: The modular and declarative nature of Soong, combined with Ninja's parallelism, makes the build system more scalable to the ever-growing size and complexity of Android.
Pathway to Bazel: The Android.bp file format is intentionally similar to Bazel's BUILD files, indicating a potential future direction for the Android build system to fully embrace Bazel, a highly scalable and reliable build system used by Google.

Challenges and the Road Ahead

While Soong offers substantial improvements, the transition from Make has not been without its challenges. The migration of a massive codebase from one build system to another is a complex undertaking. Developers have had to adapt to the new Android.bp syntax and understand the underlying principles of Soong.

Furthermore, dependencies between legacy Android.mk modules and new Android.bp modules can sometimes be intricate. While Android.mk modules can depend on Android.bp modules, the reverse is not always straightforward.

Looking ahead, Google is actively exploring the integration of Bazel as the ultimate build system for AOSP. Soong serves as a crucial stepping stone in this evolution, providing a modern foundation that is more compatible with a Bazel-like philosophy.

Conclusion

The Android Soong build system represents a pivotal advancement in Android platform development. By moving away from the limitations of Make and embracing a more declarative, performant, and scalable approach with Android.bp files and Ninja, Soong has significantly improved the efficiency and reliability of building the world's most popular mobile operating system. As Android continues to grow and evolve, Soong lays the groundwork for even more sophisticated build capabilities, ultimately contributing to a faster and more seamless development experience for the entire Android ecosystem.

Try this instead of pip for your python projects

Bharat Dev Burman — Thu, 06 Mar 2025 17:11:31 +0000

I discovered this shiny new tool called uv while trying to have my python dependencies managed better just like yarn for node projects.

It is not just fast but blazing fast.

This tool made me work much faster and spent less time staring at the screen.

Checkout the post on X

My Journey with Android

Bharat Dev Burman — Fri, 11 Oct 2024 10:33:01 +0000

My journey began with getting my first smartphone back in 2015. It was a Xiaomi Redmi 2 and had its bootloader already unlocked. This was very enticing as it opened some doors for me to experiment with that device.

Then I found XDA developers – a forum dedicated to share and collaborate aftermarket operating system development based on AOSP. I quickly learnt that it was the base of all the Android powered smart devices.

After that, I came across the Linux kernel and how Android is based on it. On visiting the AOSP's website, I was mesmerized with the size and complexity of the code base and how the entirety of it is built. I also discovered something called as the Team Win Recovery Project, TWRP for short.

After getting my second smartphone, the Redmi note 4(x), I experimented further and I got addicted. Now this was bad as it took away my free time meddling with my phone. But it didn't stop me and went ahead with my next smartphone: Samsung Galaxy A30.

I wanted to get a headstart on the development so I voided it's warranty and unlocked the bootloader. Samsung is a different league altogether as it they also use to their own chipset (Exynos) and security measures (Knox) which was a hindrance. I nevertheless managed to port LineageOS. I felt great and then I joined a public Telegram group chat dedicated to this device and exchange knowledge. I eventually got fed up of this distraction and swapped my phone with my Moms’ – a Lenovo mobile. She was happy to get an upgrade in performance.

That Lenovo mobile was actually more irritating as it was older than the Galaxy A30 and had a mediatek chipset. I started to understand why Qualcomm Snapdragon is way better. It unfortunately broke and I used an even older Sony Xperia as having a phone became a necessity.

Time for another device – this time a Realme phone. I created and maintained a forum for this device. I also officially maintained the TWRP recovery for this device. The chat still exists till date with 700+ odd members. I handed over the responsibility to someone else to focus on college.

All of this might have taken away my precious time on something I do for free but I'm proud of my achievements.

That's what matters – to think about the good stuff and not crib about what one couldn't do.

Make mistakes; It's fine

Bharat Dev Burman — Fri, 19 Apr 2024 13:50:48 +0000

It's alright to make mistakes. Everyone does. But it's very important to learn from them and change your approach on how you solve problems.

Programmatically, writing Unit Tests is a must. It helps you prevent overlooking certain edge cases and sometimes the obvious like nullity.

Hello, World!

Bharat Dev Burman — Mon, 18 Mar 2024 02:31:07 +0000

Hello, World!

I am, at the time of writing, a student pursuing Masters degree in Computer Science, and an origami artist. This art was the actual reason for getting interested with the field of Mathematics and over the course of time.

I have published a research paper in the IEEE journal, an amazing feat to achieve when I was just 20 years old.

DEV Community: Bharat Dev Burman

Beyond the Mute Button: How a Broken LED Led to My First Linux Mainline Kernel Commit

The Fragile Illusion of User-Space Fixes

Diving Into the Kernel & Codec Architecture

The Secure Boot & fedpkg Gauntlet

17 Hours: The Nuremberg Connection

The Mainline and Beyond

What I Learned

Kotlin Multiplatform vs Flutter: Showdown time!

Kotlin Multiplatform: Native Fidelity with Shared Logic

How it works:

KMP Advantages:

KMP Disadvantages:

KMP Use Cases:

Flutter: Unified UI and Rapid Development

How it works:

Flutter Advantages:

Flutter Disadvantages:

Flutter Use Cases:

The Showdown: Who Wins?

Choose Kotlin Multiplatform if:

Choose Flutter if:

Revolutionizing the Android Build: An In-Depth Look at the Soong Build System

From Make to Soong: The Evolution of Android Builds

The Heart of Soong: Android.bp Files

How Soong Works Under the Hood

Advantages of the Soong Build System

Challenges and the Road Ahead

Conclusion

Try this instead of pip for your python projects

My Journey with Android

Make mistakes; It's fine

Hello, World!

The Secure Boot & `fedpkg` Gauntlet