Activity
We constantly build and release new, bleeding edge versions of Haiku for testing purposes. You can download and install these versions to check out the latest features and bug fixes.
Be aware that nightly images may be unstable. Additionally, some packages included with official releases need to be installed separately.
If you're OK with this, you can find further instructions at our Nightly image page.
Introduction
The goal of this post is to document the changes I made during the GSoC period and the current state of the project.
I would also like to thank waddlesplash for his continued support throughout the project.
Progress So Far
RFCOMM Protocol
RFCOMM is now almost ready to be merged. It acts as the control channel required by HFP.
The implementation includes:
- RFCOMM socket addressing and connection management
- DLCI multiplexing over a shared L2CAP connection
- SABM, UA, DM, DISC, and UIH frame handling
- MCC commands
- Credit-based flow control
USB and xHCI Improvements
During implementation, I found that the xHCI driver assumed all isochronous packets had the same size, which is not always true.
The xHCI driver now supports variable-length isochronous packets and processes completed transfers in FIFO order instead of LIFO order.
Hello everyone! As Google Summer of Code 2026 comes to a close, it’s time to summarize the work I’ve done over the summer on expanding the functionality of the Haiku Devices application.
Overview
Haikuâs Devices application previously provided a basic list of connected hardware, but lacked the features necessary to function as a true management utility. My project aimed to transform Devices into a more capable hardware manager, allowing users to view detailed technical specifications and perform administrative tasks directly from the GUI. Over the course of the summer, I focused on implementing new visualization features, improving the user experience, and pulling more detailed hardware information directly from the system.
Hello! The GSoC’s midterm (at least for me) has just passed, so I thought of making a recap post about the improvements I’ve made so far. I’ll try to keep the post brief to make it easier for readers (foreshadowing: I realized that’s impossible :P). I’ve already posted an introduction about me and the project. You can read it here if you haven’t already.
Host-Controller Interface (HCI) Commands and Events
The Host-Controller Interface (HCI) is the specification for how the operating system (the host, in our case, is Haiku) communicates with the Bluetooth controller. The Bluetooth controller is basically the firmware on the Bluetooth chip. So, it’s vital to implement at least most of the mandatory HCI commands and events from the Bluetooth specification for Bluetooth to function properly. HCI commands and events were mostly outdated, dating back to version 2.0 or 2.1, so updating them was the first step to get the Bluetooth stack back to life.
Introduction
Hello again! It has been a fun journey since the beginning of GSoC. My project focuses on modernizing Haiku’s Bluetooth stack, specifically adding support for the Hands-Free Profile (HFP). HFP is a profile that allows operating systems to interact with Bluetooth audio devices, such as headsets, for two-way voice calls and audio streaming. Today, I’ll be sharing a progress report on the work I have completed till now, and will outline my plans for the remainder of the project.
This report covers hrev59754 through hrev59820.
Hello Everyone! I have officially reached the midterm mark of my GSoC project, revamping the devices application. Over the past few weeks, I have made a couple of changes extracting more hardware information and presenting it cleanly to the user.
Here is a look at what has been accomplished so far.
Extracting the device path and driver used
The first goal of my GSoC project was to determine which driver is loaded for a device, and display the device path as well if existent. To do this, I worked with the device_manager to get the driver path. I managed to get a hold of this in the app with a dm_wrapper call, and then display it in DevicesView by creating the devices with that new attribute. For the device path, I also used the device_manager to add the published path as an attribute, that would get fetched in DevicesView as well.
This report covers hrev59672 through hrev59753.
This report covers hrev59570 through hrev59671.
GSoC selection happened at the end of last month; you can read the news post announcing this year’s selectees. Thanks to everyone who applied!
Introduction
Hello! My name is Leo Rouleau, a first-year software engineering student at Polytechnique MontrÃĐal. I chose to apply for Haiku because of my interest in lower-level programming and operating systems. Having worked on projects involving microcontrollers and custom interpreters in C, C++, and Java, I’ve found systems-level development to be the most engaging challenge.
Project Overview
Haikuâs current Devices application provides a basic list of connected hardware, but it lacks the features necessary to function as a true management utility. This project aims to transform Devices into a full-fledged hardware manager, allowing users to view detailed technical specifications and perform administrative tasks directly from the GUI.
