I would like to get started writing drivers for Haiku. Is there any documentation or tutorials for something like this?
Perhaps overly ambitious, I have recently purchased two laptops. I am able to get Haiku to boot on both of them but there are some issues that I imagine are driver-related. I thought maybe it would be good to begin with problems that I’m having when getting started writing drivers.
Here are the issues that I have so far when I boot:
Machine 1:
Wifi not recognized
Trackpad not recognized
Using VESA graphics
Machine 2:
Trackpad not recognized
Keyboard not recognized
Main hard drive not recognized
There are other things I haven’t yet tried such as the audio, the web cam, etc.
What I’d like to do is learn by doing. So, if I wanted to start by tackling the Keyboard not working and then the Trackpad not working, where is a good place to begin?
Probably something relevant would be redirection of USB device signals to a terminal. Then start reading code for existing USB drivers. Can you use an external keyboard with the laptop with the non-functional keyboard? Other USB pointing devices? Compare their output to the output of other devices and read the driver code for the working devices.
I’d actually love a Haiku tutorial on USB redirection for this purpose. I have some Huion drawing tablets I’d love to get working. The pad part works, but no buttons.
@waddlesplash has been looking for folks who could help out with the graphics drivers for a while now. Might be a good idea ask him for help and where to start.
Graphics drivers are not for starting out. Complex is an understatement it will take man months to finish that work with developers who know exactly what the are doing already.
USB is also complex and mostly works… the bugs left are going to be hard ones.
Start with a serial device like your mice or touchpad may be a serial device (via smbus etc…), they may also simply be unsupported USB HID devices which are probably not hard to fix. You will want to get something like a Saelea logic probe or clone to probe your smbus/i2c bus or serial device even.
Another thing you could try is for example take the CH340 and port a driver for it to Haiku (make sure it is license compatible, or write your own)… its a cheap chinese USB serial device, and there are already USB serial drivers for FTDI you can get an idea of what you need to be doing. I think Haiku can regonize this device currently but doesnt’ support it yet they are cheap to buy also and easy to test since it is just a serial device.
The first thing to do is figure out what kind of hardware you are dealing with. Is your touchpad PS/2, USB, or something else? Likewise for the keyboard. How is that hard drive wired? AHCI/SATA? NVMe? What are the PCI IDs for the unrecognized wifi and graphics card?
Then, the second step is to collect information about the devices. Could be HID report descriptors, manufacturer specifications, maybe drivers from other operating systems to use as a reference, for exampe.
The plan can be different if you just need some fixes to the USB HID driver, a new type of touchpad in the PS/2 driver, or a complete new bus system for a touchpad that is connected in a completely different way.
@OneRyan, don’t be afraid to ask us for help; always a pleasure to teach new developers the ins and outs of kernel programming. Ping us on IRC with questions!
This makes sense to me. I can contact the manufacturer of the laptops (Lenovo), but I’m not immediately hopeful that I will be able to get the level of detail I need.
So I would like to learn more about how to use the available tools to investigate these devices. My imagination tells me that if they are on a supported bus, that I should be able to query the devices, identify the devices in question, and begin to experiment with them; sending commands, reading, writing, etc.
I see the Devices app, and that it appears to enumerate the devices. Does it enumerate all it finds, regardless of whether it finds a supported driver? If so, perhaps this can be used to show me what devices are available. Then, how do I begin to peek and poke at the devices to experiment?
For USB devices you’d look in listusb, for PCI devices in listdev. For PS/2 there isn’t a similar tool so you have to search “ps2” in the syslog, you can see there what it’s doing and which devices it sees.
A possible source of information is how it is handled in other OS, for example trying to look at info from users of Linux or one of the BSDs having similar problems, or looking at the drivers used by Windows on the machine (this can then tell you the device manufacturer and model, and from that you can look into specs for the specific device)
If no docs are available, another option is capturing the commands an existing driver uses (for example, I used a tool called usblyzer on Windows, or Wireshark on macos or linux for usb devices), and trying to use the same commands until you get things working
Having a goal like getting a specific piece of hardware working is a great motivator. It might also be a bit intimidating when it comes to getting started.
For me the best way to get started into something like this is to spend lots of time reading the code to familiarize yourself with how the different components of the kernel work and fit together, and also to get really familiar with the tools at your disposal.
Add new kernel debugger commands, even if they are just throw away, to help you figure out how to introspect the state of the system.
Add panic() calls into different parts of the kernel, which will trap the system in the debugger in a way that’s usually resumable, so you can trace through different parts of the code that are a little hard to understand (like some object which contains members which are function pointers and it isn’t clear what they are being set to in the context that interests you).
Get familiar with the tracing functionality built into the kernel. Add some tracing statements using dprintf() or the existing TRACE() macro in whatever module you’re looking at and use the “traced” command in the debugger to see them.
Get a working setup that lets you build and install the whole system onto a separate partition that you can boot from. Like “HAIKU_INSTALL_DIR=/TestInstall jam -q -j8 @install.” Make sure you can reliably install onto that partition and select it from the boot loader. That makes it easy to make a change and test with the whole system without breaking your dev environment install.
Learn how to blacklist kernel add-ons. Build the add-on from source and install it in ~/config/non-packaged/add-ons/kernel/drivers. That’s an easy way for you to build a new driver and test it without installing the whole system, and if you make a mistake, you can disable user add-ons from the boot loader.
Anyway, everybody’s different, but that’s usually my approach. Even without learning much about the hardware itself, you might end up finding bugs just reading the code and adding extra tracing.
After spending time tracing through the code the puzzle pieces will start to fit together in your head and it will be easier to read the driver code that exists now. Then you can find reference material that is out there on the Internet to help you understand how to support some currently unsupported hardware. Or learn how to use a logic analyzer.
Also, sometimes qemu already has code for simulating the kind of device you are trying to support, which will at least give you an easy way to test. And qemu also has nice tools for tracing what happens in the virtual device. You can use that to trace Windows or Linux or some other operating system to see how their driver communicates with the hardware.
