[GSOC 2025] Introducing Myself

Community
22

I have created a 20GB drive as @Pap advised and I think it will probably suffice for my needs. Also, I was already planning to buy a 2TB HDD. So, I will probably install Haiku there too.

The native one, built specifically for Haiku, would be Genio.

@Pap told me about Genio above. I have installed it in my system. Looks very nice.

So, do you already have an idea which of the project ideas you plan to apply for?

I have explored the OS briefly and tbh had a lot of fun in doing so (reminds me of my childhood computer with windows XP). Replicants reminded me of the windows 7 gadgets lol.
Anyways back to the topic, currently I am working on adding SDL3 to HaikuDepot. I hope that having SDL3 in the repos will be beneficial for everyone and also that this will help me to get started with contributing to various Haiku codebases which is a requirement for GSOC. If everything goes well I plan to try adding SDL3_image and SDL3_ttf followed by Mixer and Net once they get released.
Now coming to the project ideas that I plan to apply for, the ideas that felt the most interesting to me were porting SFML/Allegro 5 to Haiku (I think SFML will be more useful as there is already Allegro 4 in the repos) followed by the multi-monitor support and the complex font rendering one. I like graphics programming and working with graphical applications. I love to write C++ followed by C and Python. Ig this will help you to understand why I am interested in those projects.
Also, I don’t have any specific affinity for SFML so I am willing to port something different if that will be more useful to the community. I thought about creating a post asking about this once I am done with SDL3.
There are some other ideas too that I think I will be able to do with proper guidance.
I have one question. Are the project ideas arranged in any specific order of preference? Asking as coincidentally the projects that I am interested are the last three in the list lol.
Everyone please let me know about your thoughts on this.

1 Like
23

I suspect that he is suggesting you to port Linux GPU kernel drivers to Haiku or reimplement Linux GPU ioctl API. But it is quite difficult task that do not fit to GSoC unless you are already Linux kernel developer.

24

Multimonitor support is something a lot of people want to see in Haiku.

Don’t shoot for the moon and try to enable four or six monitors. Two will do fine for now. You could even specify that you only support one external HDMI port on laptops or one additional HDMI port on desktops. Supporting every other historical port is not necessary. You could also take a tip from Raspberry Pi (the 400, at least) and disable sound on the second HDMI.

But you’d have to think carefully how multimonitor support would integrate with Haiku’s own Workspaces system. If I have two monitors, do they get four (or whatever number) workspaces each, or does the second monitor become another “workspace”? What happens when I drag a window from one monitor to another? Does it land on the current workspace or will a drag from Monitor 1, Workspace 1 always end up on Monitor 2, Workspace 1? Can the two monitors have different numbers of workspaces? Will there be something like xrandr to specify the monitors’ positioning? Which monitor gets the Deskbar? The answers you come up with will be with Haiku for a long time.

Whether all that can be done in a GSoC project is something more experienced people will have to decide.

1 Like
25

No, they are ordered by categories. The final selection will depend mainly on the quality of the project applications and behavior and implication of the participants, secondarily on the available mentors (if we get more students than we can handle or if a mentor is only able to mentor a subset of the project ideas). The usefulness of the project idea itself only comes third. The goal is to train people to contribute to open source and ideally get new contributors for Haiku. The actual project is not all that important (even if some of them would certainly be very interesting for Haiku).

For this one, I don’t know how much work is really needed. So the best thing to do would be to try compiling them, and see how hard it really is to get things going, listing all the problems and code that needs to be written.

Even if the complete project does not fit in a single GSoC, some progress could be made in researching, documenting and prototyping. But I don’t know if it’s a good idea to start that project without the existing developers already having discussed it a bit and agreed on what should be done.

As it often happens with computer things, going from one to two is hard, but going from two to many is a lot easier. So that wouldn’t make the project a lot simpler.

We don’t have sound over HDMI at all.

I think that would be a separate GSoC project: getting the drivers (or one of the drivers, even) to initialize multiple monitors, working with the API used by the old Radeon driver, would probably be enough for one GSoC.

Once we have that, it will be a lot easier to experiment with the other part. Otherwise, it’s too big as a single project. But it could maybe be done as a stretch goal.

2 Likes
26

I suspect that he is suggesting you to port Linux GPU kernel drivers to Haiku or reimplement Linux GPU ioctl API.But it is quite difficult task that do not fit to GSoC unless you are already Linux kernel developer.

I see. I have some experience with mesa drivers due to trying to get hardware acceleration working in termux (which is basically a android app trying to provide a linux environment). But that was mostly with zinc and virgl and that too quite limited. So, ig as you mentioned I probably don’t have the know how to successfully complete it.

1 Like
27

For this one, I don’t know how much work is really needed. So the best thing to do would be to try compiling them, and see how hard it really is to get things going, listing all the problems and code that needs to be written.

I see. I am somewhat familiar with the SFML code base even though I have never contributed directly to the project. I will follow your suggested approach and try to create a proper roadmap with all the needed actions.
If after the estimation we find that it might get finished early can I make my proposal in such a fashion that I will port a number of applications instead of one?
Also, what are your opinion on the complex text rendering project? I have some experience on that since I have contributed the GPU Text Engine API to SDL3_ttf. While my api only exposed the necessary information to draw the text with SDL_GPU API (there is a plan to make it more generic such that you can use it with other graphics apis like vulkan and opengl), the underlying text object api is really excellent. It supports kerning, ligatures, SDF, and all other magic needed to draw text of these complex languages. I was thinking that maybe I can directly utilize the SDL_ttf api (I am not yet familiar with the internals of app_server so not sure how practical this is) or maybe write something inspired from SDL_ttf’s implementation. This way we can have something that is battle tested. I think this is a good way approach as it would be very hard for us to check for errors in every language otherwise.

Also, I have a good news. I have managed to build the hpkg file for SDL3. Thanks to the great work by the SDL devs the recipe should be even more simpler. It’s too late today so I will try to install it tomorrow.

1 Like
28

Complex text rendering probably should be done by using harfbuzz. We already have freetype for the rendering itself.

29

Yep. That’s what SDL_ttf also utilizes internally. You can build it without harfbuzz to use freetype only but I have seen people reporting quite a few issues with that especially with non english text. And a lot of them felt like a freetype issue to me.

30

Freetype and Harfbuzz have different purposes, using “only” freetype with complex scripts won’t work as it does not support the font shaping required.

31

You are correct freetype doesn’t even support GPOS kerning. I faced this issue while trying to use a english font that utilized it. Let alone complex languages like arabic or hindi.

32

I’m not sure that is a good use of GSoC time. The idea of GSoC is that you can spend a lot of continuous time focusing on a specific problem. Working on many smaller ports does not need that, it is something that can be done with a few hours here and there.

So, the project would get boring and repetitive, and would not use the opportunity to learn as much.

We don’t plan to use SDL in app_server. We probably need to implement something similar, tying harfbuzz and freetype (and maybe fontconfig) together.

But I think the rendering of text is the easy part in that project. That is just following the examples (in SDL3 or other places) and the documentation of the libraries to use.

What gets more interesting is things like cursor and selection management, handling of partial redrawing, and also good adaptation of the user interface for right-to-left text.

When you have text full of ligatures or combined characters, what happens when you try to select and copy parts of it? When you move the cursor accross? When you backspace a character and retype it? A lot of the text handling in Haiku is built around the assumption that one unicode codepoint = one glyph, which of course isn’t the case at all. For example, our API allows you to do this:

DrawString("this stuf");
DrawString("f is hard");

And you should get the same result as:

DrawString("this stuff is hard");

To achieve this, the BView API keeps a notion of an internal “drawing position” that advances as text is drawn. And it’s also possible for applications to retrieve, save, restore, and move that position.

But what if the “ff” is replaced by a ligature? This cannot happen in the first case, because the two parts are drawn separately. It may seem silly in this simple example, but this could happen, for example, if a view is trying to optimize things and redraw only a small part of the text that was exposed by another window being moved out of the way. So, how is that supposed to work? How do we determine a “safe” part of the string to redraw?

2 Likes
33

Sorry, for replying late. We had a lot of classes today and I fell asleep after coming back home.

I understand your concerns regarding the multiple ports and now that you put it that way I think they are very justified.

Currently, I am trying to install the SDL3 hpkg file that I have built yesterday. If everything goes well I will create a draft PR in the haikuports repo.

After that I will divert my attention to SFML and or Allegro to give you guys a accurate estimation of the work needed. After that if you think it is justified for a GSOC project then I will give my attention towards that or focus on the text rendering project.

Also, can somebody kindly point me to where should I look to understand the inner workings of the app_server well? I have found this page through a google search: Application Server — Haiku internals documentation and thinking about starting from here.

2 Likes
34

I have created a draft PR for the sdl3 recipe Added recipe for libsdl3 by captain0xff ¡ Pull Request #11770 ¡ haikuports/haikuports ¡ GitHub. Sadly, it appears that keyboard events are not being registered. I am looking into it. Maybe I should also create an upstream issue.

35

Only if you wanted to work on implementing Haiku’s Kernel DRI.

Migrating legacy SDL 1.x apps → SDL 2/3 seems another option…

36

Only if you wanted to work on implementing Haiku’s Kernel DRI.

Oh. As I have mentioned above that is probably above my skill level.

Migrating legacy SDL 1.x apps → SDL 2/3 seems another option…

Will that be a relevant Haiku project for GSOC though? Also, there is sdl12-compat and sdl2-compat, and chaining them is supported too.
I am curious though, is there any actively maintained and used project that is still using SDL1? As even if not a GSOC project that can be a fun side project.

37

Last I tried on Linux, SDL12_compat didn’t work with the Protrekkr music editor, forcing me to statically link SDL 1.2.15 to the editor. It may be fixed in the latest version, however. See GitHub - hitchhikr/protrekkr: Tracker/Synth program for more details. In short, the text in the Tracker window didn’t render in SDL 2.x nor 3.x .

38

Probably not, as it is completely unrelated to Haiku, and, as you mention, solutions already exist.

1 Like
39

No. Indirectly, as for software (applications) development and FOSS porting projects in lieu of using Allegro/SFML/GTK+ versus SDL.

Just noting SDL1->SDL2/3 migration - but not sidelining your GSoC work.

40

Last I tried on Linux, SDL12_compat didn’t work with the Protrekkr music editor

Can you create a issue in the SDL compat repo? The SDL maintainers are currently focusing on the compat libs since SDL3 released recently and so your issue might get fixed very fast.

41

Just noting SDL1->SDL2/3 migration - but not sidelining your GSoC work.

Oh got it. Sorry, for the confusion.