Hi,
If you are a student, one way to handle it is to apply for Google Summer of Code which will happen in a few months (assuming we get selected this year). This is something we know how to handle on Haiku side, and the nice thing about it for us is that Google would be paying for it.
If things go well during GSoC, we could then continue after it with a contract funded by Haiku inc.
On our side I think this would be the easiest thing to set up. Would it work for you?
More about summer of code:
Thanks, I did look into this, the main thing for me is the timings; as a sort of internship, it definitely wouldn’t be considered by the banks, and as I would need to evidence something like three months’ pay then that puts everything back to the end of the year, which is not ideal for me. If it were the case of doing a couple of things at the same time then it may be a workable option, depending when I hear back from some other places I had asked, but I totally understand that from your end this makes more sense.
For future lurkers… I did a survey recently (80+ responses), and these are the top things to likely be considered based on community feedback (in no specific order)
Those two things are what most people say are the “most lacking” today. (and just so happen to be really complex projects… go figure 
)
The most complex part of this is fighting with Linux headers that are the mess. It redefine a lot of compiler-specific declarations. I plan to try at least compile some DRM kernel drivers. My previous 2 attempts were failed, but I didn’t spend enough time yet. I will try again when I have time.
WebPositive definitely really important, personally I loathe web stack/HTML so probably wouldn’t be best placed for most of the work, however the acceleration sounds an interesting area. I’ve just got the solaris machine installed and one thing I was hoping to do is use waypipe so that I could run wayland sessions in the VMs and log in remotely - currently I believe VNC is offered but this presumably requires emulating a graphics card, running X, compressing that out and putting over a socket, etc. etc. There’s a tool called waypipe that can pipe the Wayland session and (I believe) use the local OpenGL/graphics accelleration to do the actual rendering, and this can simply be accessed over SSH so it seems ideal for remote logins and a basic test worked beautifully between two arch machines. First task is to get this working inside the zones whilst logging in remotely but I’d be interested eventually in trying to port wayland to solaris so I can view on the same device. So, know you said really complex XD, but at the least I’d have an investment in looking into something like this, separating out the linux-specific headers and maybe making it more POSIX-friendly if this would help build on illumos (or BSD first - actually I should look and see what ports they have already). Anyway, I saw a bug relating to the RTTI in GCC2 libraries, this is very similar to the standards proposal paper I wrote a while ago so thought after trying a few toy bugfixes to get started this might be a good place to look into.
I am going to start getting back up to speed on WebKit and WebPositive and related things, though this week is quite hectic as my son’s birthday is soon and we are getting ready for that, plus work, etc. But I at least have the motivation. But man, what a codebase…
Regarding stellarpower and a contract, I know people want GPU acceleration and better video card support in general, but I think there are many other lower hanging fruit which could really improve Haiku without being some intense years long project. I think those are the things we should focus on for now, both for volunteer developers and contractors. Though since contractors are being paid, they can work on some of the things volunteers might not want to. It doesn’t mean these are terrible, drudgery tasks, just maybe more annoying or detail tasks, which maybe would be good for stellarpower based on your mini biography above.
But like I said in my first post here, please try to pick a bug or two to tackle, get a Haiku development system going, and get some patches accepted in Gerrit. Also maybe start browsing tickets in Trac and build up a list of some of the bugs that interest you, or bugs where your past experience might help in solving. Don’t worry too much who owns the bugs, you can always post a comment and change ownership if you start working on something. Though I do know a whole lot are under “nobody”, which means what it sounds like. I think it is safe to say there are bugs and features to work on in just about every possible area of computing. Haiku is a great environment to work on a wide variety of programming tasks!
To be honest my main concern right now for having a single contractor is getting changes reviewed in Gerrit quickly, especially as that contractor gets up to speed. Eventually they will know their way around and can also help review work from volunteers, but I have some concern about patches sitting around too long. The contractor, whether stellarpower, or someone else, may need to structure their work so that changes in Gerrit can sit a week or so until volunteers have some time on the weekends. This may be okay, given the relatively slow pace of Haiku and currently no concern over urgent “production” bugs. But it should be taken into account and a contractor should not be upset if changes take some time to get reviewed. Just wanted to lay that out 
Hey,
Haiku doesn’t have wayland nor X11, we have our own server called app_server that is responsible for drawing applications, drawing fonts etc, we also have a html5 remote desktop for that but it still is kind of buggy.
Not sure why vnc would require X11 (except maybe in the running the vnc client on some application server sense)
Personally I think tasks like a resumeable app_server (applications reconnect after a crash) or the html5 client getting a second app_server instance and improving that client might be worthwhile tasks for a contract,
Perhaps also multi monitor support.
I wouldn’t say that of WebKit. There are a lot of small tasks that can be done and that are not complex at all. Starting with the most boring thing: watching WebKit repository, merging the changes from time to time, and fixing the build. This does not need any advanced skills. But currently I’m the one doing that, and I can only spare time for it once every month or so. Which means I spend a weekend merging things, and then I have no time to do anything else. If there was someone else doing this work, I could focus on the next step, maybe, upstreaming our work to WebKit to make this whole process easier.
Anyway, the main blocking thing for WebKit is not WebKit related at all. We need to release beta 3 and update the buildbots so I can ship a new WebKit release with many already done bugfixes. This (combined with leorize’s and nielx’ work on the HTTP APIs) would already solve several of the problems with the current version.
After that, there are still a lot of not particularly difficult things to do. WebKit is big, sure, but the parts we are touching aren’t all complex.
Hopefully we can hire a developer to just do this!
You may want to try with OpenBSD or DragonFlyBSD’s versions of the DRM drivers. They are older than upstream Linux, but they also mostly use BSD or BSD-like APIs directly, so you may be able to lift a lot of code from the existing BSD compatibility layer, or at least get a handle on things faster.
looks like OpenBSD have a higher Linux version than DragonFlyBSD’s .
gitweb.dragonflybsd.org Git - dragonfly.git/history - sys/dev/drm
DRM update committed (undeadly.org)
and DragonFlyBSD’s has a IRQ Linux implementation.
DragonFlyBSD Implements Part Of Linux’s IRQ Subsystem, Improves DRM Driver Portability - Phoronix
Maybe taking care of Intel drivers would also help. From what I’ve seen, most frustrations come from having to blacklist stuff at first boot. If people could get picture without any issues, I doubt they’d be that frustrated.
But if the greater goal is to use all drivers from Linux or BSD-verse plus DRM, all effort should go there first.
That is debatable.
Personally I am annoyed at this approach, where everyone just relies on Linux to write the drivers, and Linux relies on the hardware manufacturers to do it. Eventually this means all the knowledge about graphics driver in the community is lost and we are fully dependent on the corporations to provide us with drivers, it makes me a bit sad.
On the other hand, maybe it is easier (I’m not even sure about that).
That’s not the only thing. In my case the driver works fine for the internal display of my laptop, but I cannot use any external display. This is very annoying, because I have a much larger and much better display at home. As a result I do not use Haiku this much, and, for example, I am less interested in getting it to play Youtube videos properly because I have to watch these on a different computer anyway. If Haiku had dual screen support I would use it a lot more.
Also annoying is that I several time spent a few hours looking at this Intel driver and couldn’t understand why it’s so close to working, but there is always something slightly wrong and I can’t understand what it is. The work is maybe 90% done, but without the remaining 10%, it’s all useless. And like for web browsers, the dominant approach is “oh we should just restart from scratch, ignore all the work done so far, and port Chrome/Linux video drivers”. Maybe I am unreasonably invested in the native solutions.
AMD has docs on their gpus (maybe not all, i have not checked) but certainly for some, I’ve bern playing around with the idea of building a driver.
I am not a fan of porting linux drivers really, it could bring some nicer gpu 3d support but that seems a bit effort vs reward kind of thing, I think it makes more sense to have drivers we can actually debug ourselves in the long run.
(I also had incredibly bad experiences with linux drivers crashing constantly on oses that had ported them, Personally i think stabilitiy is more important that absolute performance, and therefore think it is fine for the driver to crash, but not for it to bring down the system as a result, so I favor a usermode driver, if this is feasible)
One can though use the drivers in linux as a reference for building a new driver too, since the intel and amd ones are mostly mit afaik.
for nvidia i simply wouldn’t bother currently.
There are too many kind of hardware so even with good will, you won’t be able to achive this on your own. Therefore, maybe try to approach manufacturers. Show them that Haiku is different and has a lot to offer. That it would be sad to use ported drivers and not take advantage of Haiku design. Ask them what they would need to write drivers and how you could cooperate. Even if they don’t do it themselves, they could provide infos that would help in the design of the architecture needed, of a toolkit and docs necessary for the one who will do. You could also use these infos to make a “simple” driver that can be used as an example.
That argument applies to every hardware, maybe we should just not make any drivers if it is impossible to make one for every piece of hardware by a single person…?
I think it is perfectly possible to make drivers for specific pieces of hardware, why shouldn’t it be?
The intel extrem I have works with external vga output. I have to connect the VGA cable and restart my laptop. I have to do it manualy so no problem. Hotplug is not possible.
I will get 1920 x 1024 with cable, and 720 x 576 without cable on Laptop.
For easy solution. Why not embed the echolog output in Vision? Or put a link to the log files in Vision? What is so difficult in open the log files in a browser window?
About Web+ I am very surprised about what it can already. It shows my AVI files and plays them! Not possible with another browser or Windows! For watchinh YouTube Videos it will be just a mattet of time and the Haiku beta3 to see these working again. Still we have qmplay2 anf Otter browser to watch Videos right now!
I really don’t know all this discussion about Web+ in connection to YouTube. Haiku is there to work first not for watching Videos all the time.
Haiku should become a heaven for all the modern developer out there first!
For the drivers issue, I believe @andreas_dr was trying to port some OpenBSD drivers, pinging him in case he might want to chime in.
Yes, it does.
I think Haiku should provide only generic drivers. Maybe few others as example.
It is already a lot of work. See how long it took for USB3.
Why do you think proprietary OSes only provide generic drivers? M$ can’t even keep up certifying them.
Writing a driver is not a simple thing. It requires knowledge and so a big community to get some pieces working. It also require testing and for this you need the hardware. This obviously takes time and and money. More hardware will be supported by your driver more the cost will evolve.
Yes, you can have few devs working on the cards they own and get here and there few hardware donations that will help but we need to be realistic. Linux didn’t manage to do it with a larger community (at least for graphic cards and printers) and proprietary OSes chose not to do it. There are certainly good reasons.
Hi, whats the question.
I am just trying to port RadeonDRM(for now) from OpenBSD to Haiku. But in the moment my time is a bit limited. I guess in a few weeks Ill have again more time.
Check here:
Many thanx