I explored the driver files again, and I think I found the driver relevant to me. But I realized that what we call a “driver” is not just a single file. Within the C files, there are references to header (.h) files, such as include statements and relational structures. It all sounds very complicated. Many files reference each other, creating a tangled web. Now I do understand what they mean when they say “architecture”. Finding my way through this is going to be very tiresome, so I found two resources to guide me: The first one is Linux Device Drivers, by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman, and the other one is The Linux Kernel Module Programming Guide by Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram, Jim Huang. I also stumbled upon a wonderful blog by an expert: https://javiercarrascocruz.github.io, which seems I’ll be visiting very often next year.

However, these books feel too heavy for me. I’m not ready yet so I’ve set another goal for myself: to practice the C language for a while. At least until I feel comfortable and I can start guessing what the code in those driver files are referring to. Otherwise it’s going to be like skimming the grammar summary of a foreign language, which I’d learn to compose well-structured texts. But I wouldn’t be able to draft even a short message with any confidence or style. In fact, I couldn’t even understand a simple text.

So I spent my Sunday going over the C tutorial again on w3schools.com and asked ChatGPT to give me a starting task, which I completed (despite a few syntax errors that I’ve learned to fix). I’ve had the chance to use the functions scanf, printf and if as well as basic math operators. I’m thinking of doing small challenges over the next 30 days (maybe even a year), at least until I reach a level where I can understand the driver code I’ll be reading. I’ll be sharing only my progress in C on this blog for a long time.

The past two weeks have been far from fruitful in my quest. My schedule has been relentless—probably the busiest I’ve faced in the past seven years—leaving me with only the smallest slivers of time to work on what I set out to achieve in my previous post.

In those rare breaks, I managed to download the Linux kernel files from kernel.org to my computer (after a somewhat frustrating hunt to locate them under Debian’s root folders). Then, I went through a sea of folders, each containing files with extensions .h and .c, without even a vague idea of what purpose they serve.

Once again, the sheer scale of what I’m attempting hit me hard. It felt monumental, almost overwhelming. There have been many moments of helplessness, where it seemed nearly impossible. And yet, there’s one thought that keeps me going: it’s difficult, but not impossible. I am committed to relying solely on online resources and tutorials available without reaching out to experts for guidance.

When things seem unnerving, I try to step back and locate my position on the roadmap. It’s been only a few weeks since I started and, well, at least now I know where drivers are under Debian (they are all .ko files now), though I don’t know how they operate. Anyway, that’s something. I will not lose heart. The busy work schedule and my foreignness to drivers and kernels are reasonable excuses for the non-progress. I will not lose heart. The busy work schedule and my foreignness to drivers and kernels are reasonable excuses for the non-progress.

The past week I braved into the realm of the C language. I started with the C tutorial on w3schools.com, and I found myself uncovering something pivotal: C isn’t just a programming language — it’s the bedrock upon which many modern languages are built. Realizing this reshaped how I view the programming landscape.

Having previously studied some Python and Swift, I was already familiar with the concepts and syntax of programming languages. However, many things had seemed abstract, as if they were building upon something I didn’t yet fully understand. Last week, those gaps started to close. As I went through the C tutorial, I began to see how the other languages rely on its fundamentals.

In hindsight, I would start with C if I wanted to enter the world of programming. Much like learning a classical language before its modern descendants, it would have given me a clearer understanding from the outset. Now, after exploring it a bit, I have a stronger appreciation for the architecture and logic that many programming languages share. That being said, I can’t claim to have learned much about C. I’ve only just scratched the surface. However, I do feel I’ve gained a general sense of its principles.

But my exploration isn’t stopping there. With a general understanding of C, I’m shifting focus toward a practical challenge now: understanding how a touchpad works. My touchpad functions smoothly on Debian, but fails to do so on Haiku. This week, I’ll begin by studying how the touchpad operates on Debian. I want to understand its internal workings, from how it detects and processes movement to how the driver communicates with the system.

This exploration is crucial for what comes next. After I gain insight into how my touchpad functions within Debian, my next step will be to dive into the kernel structure of Haiku. Only after I fully grasp how everything works in Debian can I begin to understand why my touchpad doesn’t work on Haiku. This, I hope, will allow me to approach the problem with knowledge and context. I’m really excited for what’s next. Each step forward feels like connecting pieces of a larger puzzle.

I am a translator by trade with a casual interest in free and open-source software. Over the years, I’ve explored various Linux distributions and even used one, elementary OS, for work for over a year with CafeTran. While I can’t consistently use Linux for work due to OS-dependent CAT tools like Trados and MemoQ, I always keep an eye on new releases on Distrowatch.com. I have a Lenovo ThinkBook dedicated to testing out these new distros.

Last month, another open-source project caught my eye—Haiku OS, which released its latest beta version: Haiku R1/beta5. Although it’s not a Linux distro per se, my curiosity got the better of me, and I decided to install it directly on my ThinkBook instead of just running the live version from a USB stick.

However, I encountered several issues. The touchpad didn’t work, forcing me to use a wired mouse. The Wi-Fi didn’t work either, and while I might as well connect via an ethernet cable, I prefer to avoid cables. Instead I make do with cloud services and a Wi-Fi connection. The camera was also non-functional, though I never use it, so that was no big deal. And lastly, Bluetooth doesn’t work either.

Of course, I turned to Google for solutions, hoping to find a fix for these issues, and I saw that other Haiku OS users had similar problems. Apparently, drivers are needed for these hardware, but Haiku’s small development team understandably can’t cover everything quickly. That’s when an idea struck me: how long would it take a tech layman like myself to learn how to write a driver?

I explained the issue to ChatGPT, and it provided the following guidance:

That’s an exciting challenge! Writing a touchpad driver involves understanding both the hardware (the touchpad) and the operating system (Haiku OS). I’ll guide you step by step through the process.

Step 1: Understanding Drivers and Hardware Interfaces

Drivers are essentially software that allows an OS to communicate with hardware. To write a touchpad driver, you’ll need to:

• Understand how the touchpad works and how it communicates with the system (e.g., via I2C, PS/2, or USB protocols).
• Learn how Haiku OS handles input devices.

What you need to learn:

1. Basic C/C++ Programming: Drivers are usually written in these languages.
2. Haiku OS Development Environment: Familiarize yourself with Haiku’s development tools and driver architecture. Haiku has an API for writing drivers.
3. Touchpad Hardware Documentation: Identify the exact touchpad model and find its datasheet or protocol documentation (you can use lspci or lsusb to identify the device).

Step 2: Set Up Your Development Environment

1. Install Haiku’s Development Tools: Haiku uses the GCC compiler. Install any additional development tools like git if necessary.
2. Get Familiar with Haiku’s Input System: Start by exploring Haiku’s existing input device drivers. This will help you understand how Haiku OS interacts with hardware.

Step 3: Study Haiku’s Driver Model

Haiku drivers typically follow a specific structure:

• Initialization: Probing the hardware, setting up the device.
• Communication: Reading from and writing to the device (likely over I2C/PS2/USB).
• Handling Input: Interfacing with Haiku’s input subsystem to process touchpad gestures.

Step 4: Identify Your Touchpad’s Protocol

Most touchpads either use PS/2, USB, or I2C interfaces. Use tools like lspci (for PCI devices) or lsusb (for USB) in Linux or Haiku to identify your device. Once you have the touchpad model, look for its protocol documentation or try reverse-engineering the existing Linux driver if available.

Step 5: Start Small

• Begin with a minimal driver that can initialize the touchpad and detect input.
• Gradually expand it to handle gestures like clicks, scrolling, and multi-touch.

Resources:

1. Haiku Developer Documentation: Check out Haiku’s documentation on writing drivers: Haiku Driver API.
2. Touchpad Documentation: Search for hardware-specific documentation once you identify the model.

Next Steps:

• Do you want to start by setting up your Haiku development environment?
• Would you like help finding the touchpad protocol and figuring out what tools to use for development?

Let me know where you’d like to begin!

It’s a daunting challenge, and while I’m unsure how long it would take a professional developer to write this driver, I expect it would take me years. Yet, it’s not impossible—just difficult. In fact, the idea of diving into driver development feels like a new adventure, so I’ve decided to take the plunge.

I am starting off with familiarizing myself with the C language. I’ll document my progress on this blog as I encounter new issues and (hopefully) solutions. Stay tuned!