My SDL3 port PR is mostly ready. So, I was looking at various parts of haiku itself to get a better idea of the internals and find something to contribute. For that I was reading this page: Application Server — Haiku internals documentation. And I have two questions regarding it. Firstly is the app_server swapable? What I mean by that is that like if I make a change to app_server source can I just update only that in my OS installation or I will need to install/update the whole OS. My other question is that, is the app_server API locked or I can break the API if needed? Sorry, if the questions are stupid. I have never touched the internals of an OS, only some basic experience with the windows api.
Also, if somebody knows any good tasks to get started with the app_server, apart from the ones mentioned in the GSOC page, let me know. (The ones mentioned in the GSOC page are fine too but it seems of most of them are claimed by people in the past so I am not sure about their current status).
Depends what you mean by update the whole OS. You will need to reboot to use a new app_server currently, so at that point adding a new haiku.hpkg seems easier than copying it somewhere, which would be the non-packaged directory.
You are allowed to change the app_server link protocol. Applications are not supposed to know the internals of this, only link to the application kit.
As for tasks, it depends what you are compfortable with?
On the top of my head would be:
Make the font fallback respect user installed fonts
Implement a kind of hitmap based on unicode pages if a font has any chars in that page, then we need to only check fonts that have stuff in that page for fallbacks rather than checking all fonts all the time
(maybe caching this result could be fun too?)
trim the Haiku shipped noto fonts so each codepoint has only one glyph (no ASCII chara in noto cjk, no double “emoji” glyphs in noto emoji and noto symbols)
Implement serverside rendering of BPicture (a in-memory vector graphic); add missing features to BPicture to represent everything HVIF can, and then convert HVIF to BPicture in the interface kit for icon drawing
Caching here could be cool too.
Remove the decorator api and replace it with simpler routines (i.e draw the window border, window thumb, window tab, window tab close button and zoom button) And then add these api calls to the controllook
Checkout the anti-aliasing renderer, figure out how to do this for displays that do not match LCD subpixel. Are there good alghorythms for OLED? if not can we develop them? Is it possible to detect pixel layout or maybe get this data from a databank?
Anyhow, in general check the ticket list for components you want to work on, that should also give you a start: Custom Query – Haiku
Depends what you mean by update the whole OS. You will need to reboot to use a new app_server currently, so at that point adding a new haiku.hpkg seems easier than copying it somewhere, which would be the non-packaged directory.
I see. Yeah, ig it will be most convenient to just add the new haiku.hpkg and reboot.
Thank you for listing those tasks. I will see which of them can be doable by me.
This goes a bit quickly over the details. So here’s a longer version
There are many ways to work on Haiku. Specifically for app_server, you have several choices:
Work from Linux or another OS, cross-compile Haiku and boot it in a virtual machine for testing. In that case, you can make changes to the sourcecode, then use the jam @update profile to update your virtual disk. Then, boot it and test.
Working from Haiku with the real app_server: in that case you have two options: you can build just the Haiku package (jam @nightly-anyboot haiku.hpkg) and install that in your running system using pkgman. Then, reboot and test. The other option is to set up your machine with two separate system partitions, and use one to build and deploy your changes on the other (using jam @install, after configuring that in UserBuildConfig to tell it where your partitions are)
Finally, and specifically for app_server, we have a special version of it called test_app_server. What this does is run a second app_server that shows things inside a window of the main app_server. This means you can just build the test_app_server and the test apps that go with it, and just restart that server, without needing to reboot. If you develop from Haiku, this is quite efficient as the compilke-run cycle is very fast and does not need a reboot.
And regarding API, ABI and interfaces: the only place where Haiku provides a stable ABI is between applications and libraries. So, we try to keep the existing APIs and ABI in libbe, libroot, etc. The direct interface to app_server is not part of that, and is in fact not really an API: it is a communication protocol between the interface kit (in libbe) and the server. This protocol can be changed. However, I think it’s likely that working on “complex” text rendering, will also require a review of the interface kit API in BView. Maybe the meaning of the existing functions can be slightly changed in the case of complex text (but still work in other cases). Maybe we can manage it with new flags in BFont. Or maybe an entirely new set of text drawing APIs will be needed.
For a prototype and initial implementation, maybe the best way to go is to first introduce the new APIs as needed (possibly breaking existing apps). Then, once we have things working, we can see how to adjust the APIs so that we have a way to still run old applications without recompiling them. This provides more room for easy experimentation, and allows to attack the problem of preserving the ABI with better understanding of what we need to change.
Thank you for the detailed reply. I think I will either go with the first workflow or the third.
Also, I like the way you recommend to approach the text rendering problem. I think if we first go without caring about breaking the API or ABI and create something that works well then it won’t be very hard to adjust it to match the existing Haiku app_server APIs and keeping the number of API breaks minimum.
Another thing, I was thinking about making a simple text box widget thingy as a prototype in OpenGL before the start of GSOC. I don’t know if I am underestimating the effort needed to get something like that in a working state. But I felt that something like that can serve as a nice playground to test and demonstrate the various design related questions (about which you mentioned in your comment here: [GSOC 2025] Introducing Myself - #32 by PulkoMandy) that needs to be answered before diving in the technical aspects of this problem. Also, hopefully this will help me to get more familiar with the freetype and harfbuzz api so that I can tackle the challenge more graciously during the coding period.
Let me know your thoughts about this.
Just to inform everyone, my SDL3 recipe was merged yesterday with the guidance of the reviewers and so SDL3 should be available in haikudepot now. There was a keyboard issue which was recently fixed so there is a patch backporting it to the current release. Also, I found another issue for which I have created a upstream PR. It’s a very minor issue that is only encountered during closing the app so I am not sure if I should backport it or not. Here is a link to the PR: [Haiku] Check if the returned _SDL_GLView is null or not by captain0xff · Pull Request #12303 · libsdl-org/SDL · GitHub
Hi, I am facing a problem while installing haiku on bare metal. I was following this guide but none of the things I tried seem to work. Here, is the configuration that I am trying to use:
menuentry "Haiku" {
set root=(hd1,1)
chainloader +1
}
I have two drives and the partition containing haiku is the first one in the second drive. In linux it is shown as /dev/sda1 since the first disk is a nvme ssd and named as /dev/nvme0n1p1.
But irrespective of whatever I try grub just shows efi file not found.
EFI booting works differently, the config you are using is for mbr. You have to figure out how to configure grub in efi mode, and also copy the haiku efi loader to your esp
Right, there were actually quite a few issues here and after jumping around them I have finally been able to configure grub to boot haiku but I have 2 concerns. Firstly, the max res that haiku offers me is 1400x1050 both in the boot menu and in the screen app. The next problem is that even though the haiku drive is partitioned to be 128gb. Haiku shows the drive size as 931gb which is the whole size. So, I am concerned if it will overwrite data in the other partitions.
This likely means your driver is “framebuffer”, the efi fallback driver. The resolution can only be set once at boot time. You can try adding the vesa settings file with the correct resolution and rebooting.
The Boot menu in the loader indeed seems to show the size of the disk and not the partition, this confused me too (and may be a bug). But has nothing to do with how the booted OS sees the disk
I have a final question which is, I was reading that realtek devices are problematic in haiku. So, is it still the case? My wireless usb adapter works but the speed is like 20KiB/s and downloads constantly fail. While it’s more or less fine when I use usb tethering from my phone. The speed is far from my actually internet speed but at least I get like 500KiB/s.
Realtek wireless devices should work much better on the nightlies than the beta (I merged some very recent changes from FreeBSD that improve performance significantly.)
I am on nightly. I will try to report a bug (Nvm it was not meant for me, though I am on nightly). Currently, trying to get audio working. I have installed the opensound package and disabling the hda driver.
Also, tbh this resolution problem is quite painful. None of the offered resolutions have a aspect ration of 16:9. And trying to read text from this streched screen is giving me migraine lol.
Update. I have managed to build haiku from source both from inside haiku itself and cross compile from linux. The linux way felt faster especially because of the slow network issue in haiku about which I mentioned above.
