Haiku Contract Report: October 2021 | Haiku Project

Any chance to ask who wrote that code?

1 Like

@waddlesplash could you clarify whether any changes are needed for kernel add-ons at haikuports after the switch to gcc8 for the x86 kernel? I suppose they can continue to be built with gcc2 (C interface).
For instance vmware_addons installs user and kernel add-ons, which makes a switch a bit difficult.

+1 for that. USB Wifi support would be big game-changer for me, Haiku-wise.

Thanks for all the work @waddlesplash , and of course also to all the people who donated.

From Gerrit comments on the change (https://review.haiku-os.org/c/haiku/+/4515):

This does not even break whatever BeOS ABI we yet preserve here as those APIs were C only (I think most of them are broken at this point for other reasons, though.)

I guess this means it should be possible, but it was not tested? Will we need some libgcc hacks like we had to do to use gcc8 ffmpeg with gcc2 applications?

As long as they don’t use any private kernel C++ APIs, they should be OK for now, I think.

One of the best things haiku needs is the framebuffer driver to not only work at one resolution, but to handle the availible resolutions for monitor by EDID. One thing which … at the moment is missing.

It is not possible. You can blame the developers who wrote the EFI framebuffer specification (probably someone at Intel, Apple, or Microsoft) for this. They decided that switching resolutions after booting the OS wasn’t a needed feature.

Hey, @waddlesplash!
Can you take a look at QtWebEngine and try to fix crashes? It would be nice!

This would be a dream yes.

Yes, I do plan to at some point, if necessary. I need to confer with @korli and @3dEyes, though; they may already be working on that already.

10 Likes

I only fixed one kind of crash during webcam detection. As for the spontaneous crashes on some sites like youtube, I have no thoughts on that, except that it’s probably related to V8.

2 Likes

Yes it’s very necessary. Whole community will say thank to you!
Btw, maybe this patches from OpenBSD will be helpful in someway: ports/x11/qt5/qtwebengine/patches/

The port is already based on these patches. There is no other way to build a portable vertsion of Chromium/QtWebEngine, Google does not want to upstream anything else than Linux, Android, Windows and MacOS support. So if you use any other OS you have to rely on OpenBSD people doing the hard work and providing patches.

4 Likes

Actually Korli used FreeBSD patches AFAIK …

That should be a good reason to think twice before putting any work into it.

Don’t get me wrong, I nonetheless appreciate the hard work that is put into porting QTWebEngine.

1 Like

I didn’t invest much time on that. The build time on my box makes this unpleasant.

How long?
On my Rizen7 3700X+NVME disk it takes about an hour and a half.

At first time without incremental build?

Yes. It’s a time of complete build from scratch.

a full build takes here more than 14 hours.