Haiku uses a FreeBSD network compatibility layer to support many network devices (ethernet and wireless) using drivers written for the FreeBSD project. This allows reusing network drivers with very little changes, considerably decreasing the effort needed to get good hardware support in Haiku. However, this layer only supports PCI devices, and doesn't work with USB ones. Adding support for USB to the compatibility layer would bring us support for a range of devices like so-called USB tethering, as well as USB to Ethernet and WiFi dongles.
This project consists in importing one or more USB network drivers from FreeBSD into Haiku sources. The compatibility layer should then be extended to expose the FreeBSD USB APIs to the drivers, and forwarding the calls to Haiku's USB stack. Other parts of the compatibility layers may need to be extended as well.
ACPI Video Extensions, as specified in ACPI Spec 4.0a Appendix B, adds special support to handle multiple output devices such as panels and TV-out capabilities, brightness control as well as special power management features.
Our Firewire stack supports DV receiving, but not controlling the A/V device (ie play/stop). This requires to modify the Firewire stack for FCP frame support. See AV/C Digital Interface Command Set General Specification for reference.
Ticket for support of USB isochronous streams.
We don't yet support floppy drives
Haiku has currently no support for SD Host Controller. Implementing a stack with support for SDHC PCI devices would be a good start. This would involve designing and developing a SDHC PCI bus driver, a MMC bus module and a MMC SD disk driver.
To develop and test, QEmu (from 2.3) provides an emulation for SDHC on PCI: -device sdhci-pci -sd my-test-drive
Haiku does not currently support hardware acceleration of 3D rendering. Using the Gallium infrastructure from Mesa, the goal of this project is to make the existing Mesa renderer allow 3D rendering and not just software. This involves extending the API used by our video drivers (which is currently 2D oriented only), and making Gallium uses that API. Parts of the DRI/DRM model used on Linux may be reusable, but cooperation with the app_server must be possible.
Haiku currently doesn't have a driver for NVidia video cards, and falls back to VESA for those. While our VESA driver is reasonably fast, it can't set the native resolution on all systems, leading to a suboptimal Haiku experience. Nouveau is a graphics driver for NVidia video cards. There is a fork called PSCNV which might have less dependencies on Linux. cf. https://github.com/pathscale/pscnv/wiki
The BootManager needs to be updated to have multi-drive support or needs to be replaced.
Haiku currently lacks a UEFI boot loader. The code for making Haiku build an UEFI application with the boot platform already exists. You will need to write the actual boot code that sets up the CPU to boot Haiku.To your help you have the boot code for BIOS x86/x86-64 and serial debugging with printf. Development can be done in QEMU with UEFI firmware and serial output. UEFI API is very simple and learned quickly, major skill needed is booting x86-64 platform. This does not have to include Secure Boot.
Haiku code to load the kernel is located in src/boot/platform. You can see the different implementations. The EFI version in that tree builds the bootplatform code, can run as a EFI application, can call EFI functions, but not much else. What needs to be done is setup CPU, MMU, handle kernel args, load kernel, some drivers (at least Vesa) that uses BIOS functions needs disabling. Basically everything needed to setup and boot a x86_64 platform once the EFI app is started is missing. Userland tools for EFI is also missing, so modifying and viewing boot options could also be part of the project. It would need a driver for Runtime services and an application to set/get variables.
Haiku already has some power management support in the form of a CPU idling driver. This is however clearly not sufficient, and there is room for improvements in several areas in order to make Haiku use less power and make laptops running Haiku last longer on battery.
Some investigation is required to identify the main issues in Haiku leading to suboptimal performance. There are however a few already known problems:
Link to idea on devopment wiki.
Haiku has great support for its own file system, but most others are only available read-only. It is way better for interoperability with other systems to be able to write to these disks from Haiku.
The goal of this project is to complete the existing support for one of the following filesystems in Haiku, working from the existing code base:
Haiku has great support for its own file system, but is completely missing support for some other fielsystems. It is way better for interoperability with other systems to be able to read and write to these disks.
The goal of this project is to port one of the following filesystems to Haiku:
It's okay to port over the code from other systems, although we prefer code that can be distributed under the MIT license.
In Haiku emails are stored as individual file with extended attributes. The IMAP protocol exposes mails in a folder hierarchy and makes it possible to "browse" a remote mail box. Mounting an IMAP account as a local file system is therefore a natural fit. The file system should have full read and write support (deleting mails (files), creating folders, and moving mails between folders, etc.) with local caching for better performance. The design of netfs and nfs4 implementations for Haiku, as well as the simpler googlefs can serve as a reference on how to implement a network file system.
Unlike x86 systems which have a PCI bus, most ARM devices have peripherals at hardcoded addresses. This means automatic hardware discovery is not possible. The Linux kernel developers designed a solution called "flattened device tree". It is a static description of the hardware, telling the kernel where devices are located and which driver to use.
Haiku plans to use device trees to support several ARM devices with the same kernel. This requires updating our drivers and driver infrastructure to not rely so much on the PCI bus. This work should start with the USB EHCI driver, in order to provide at least one mass storage solution to the ARM port of Haiku.
The ARM port of Haiku is currently in an early state. This project may involve debugging of other issues in the port to get it running further, so the device tree part can be tested. Several parts of the early boot code should be reviewed to make use of the device tree and remove hardcoded addresses (RAM mapping, framebuffer, serial port, etc).
The Haiku kernel provides two kinds of caches for use by file system implementations: the file cache and the block cache. The file cache caches data at the "file" level, while the block cache is used at the "block" level and is used for on-disk structures as well as file data.
The file cache uses physical memory pages directly and it is linked with the VM subsystem, so that pages used for caching are freed automatically (in a least recently used order) when running low on free memory. The block cache, however, uses mapped memory (via the slab allocator) and freeing memory in low memory situations is handled via the low resource manager.
The first problem with the current implementation is caching imbalance in favor of the block cache: it tends grow more than needed and prevent the file cache to get enough memory.
Another problem is the use of large amounts of kernel address space by the block cache, which can be problematic on 32 bit architectures. This makes the block cache constrained to the 2GB of memory available for the kernel in Haiku, and sometimes makes the kernel run out of address space for other uses.
The goal of this project is to create a common underlying mechanism (using `VMCache`) to unify both caches and move the block cache out of the kernel address space. The following problems need to be investigated and solved:
Replace GNU C library and utilities with BSD-licensed equivalents
Haiku Bluetooth Stack implements only basic functionality on lower and middle layers. This functionality needs to be completed and Bluetooth 2.X and later possibilities explored. This task involves investigating the current state of the Bluetooth code, checking that the basic functionality is still working (pairing devices, etc), and improving the stack to make it more useful by implementing drivers for a Bluetooth device of your choice (audio, HID, networking, etc).
Port the PPP implementation to our new network stack. Add phone-line modem support, including HDLC framing and VJC compression (porting both algorithms is sufficient, but make sure the license is compatible to MIT). Implement CHAP authentication. Find and fix bugs.
Implement and test SCTP, a message based transport layer protocol similar to TCP and UDP. It should comply with current IP and IPv6 implementations and provide similar programming API as BSD.
The base framework for IPv6 support was implemented as a Google Summer of Code 2010 project. Even so, there remains a lot of smaller cleanup/finalization tasks that can be done as a project.
The WebKit browser and some other Haiku applications such as HaikuDepot use the Services Kit as a network backend. This is a library similar to curl or soup, but nicely integrated into the Haiku API for easy use in native applications. The Services Kit is still a work in progress, however, and can be improved in several ways. The work on this task could include:
Many Haiku applications are using their own edit view to provide basic editor functionalities. All these implementations work a little bit different and create an inconsistent user experience. One solution is to provide a modular and powerful editor view that could be used in various Haiku applications.
The edit view design should be modular and extensible to make it easy to implement e.g. following features:
Reuse of existing syntax highlighting libraries may be possible, provided they can be connected to a native Haiku view. MIT license would be preferred for the external library.
While our MediaPlayer has support for external subtitle files, the Media Kit itself has not. The most obvious downside of that is that there is no support for subtitle (text or bitmap) embedded in video files within the MediaPlayer or other applications.
Your job would be to design the necessary API extensions to let subtitles fit in with the rest of the Media Kit, and add native support for them, which will then be available to all applications as part of the framework.
When more than one soundcard is attached to Haiku, you can only change the default input/output in the Media preferences, or reconnect media nodes manually via Cortex to another input/output device. The Media Kit could support default nodes per application (either unset (system default), or set to a specific device), and the Media preferences could offer an UI to change this.
Additionally, applications like MediaPlayer, and SoundRecorder should be able to change the input/output device within the application, too (which would just be another way to alter the described Media Kit functionality).
This functionality should only be visible if there actually is more than one audio device attached to the system; if a device is not available, it should automatically use the default output instead.
Part of this work would be to implement non-volatile storage that the Media Kit uses for each application that is connected to it, and the ability to detect the application on next start. This storage could then also be used to remember other per application sound settings in the future (or if time permits) like the balance, and relative volume.
The media kit and related applications in Haiku relies a lot on the BMediaFile being seekable. This makes it difficult to use with non-seekable media sources such as internet streams or DVD media. Rework what's needed to get them working properly.