Haiku Activity & Contract Report: January 2022

For a bit of a change this month, the usual Activity Report is hereby combined with my Contract Report. (Thanks to PulkoMandy for all his hard work writing the activity reports most other months, and for all the work he put into this one before turning it over to me for its completion. Now I get to write about myself in the third person!)

This report covers hrev55769 to hrev55835.

Build system

kallisti5 fixed an infinite recursion in a Jamfile when doing a “host-only” build (where no parts of Haiku itself are actually compiled, only tools that run on the host system).

waddlesplash fixed some issues in the build tools that led to incorrectly set access and modification times in generated packages. The date would be set to the date of the package creation for all files, which confused makefiles and other buildsystems run in the resulting Haiku install in thinking everything was updated. Now the files preserve their modification times from the git tree, so their dates do not change if the file is not actually modified between builds. (However, this functionality is not yet taken advantage of in the default nightly builds generated by our CI … more work is needed on our infrastructure.)

Applications

Mikael Konradsson fixed DiskProbe to use the “shine” and “shadow” colors from Appearance preferences instead of tinting the base color. Humdinger fixed insets for the scrollbars in DiskProbe, which were misplaced by 1 pixel.

korli improved mouse handling in Terminal for ncurses and other text mode applications. The mouse button press and release events were not correctly implemented.

John Scipione fixed the display of thumbnails (image previews) in Tracker, which had been broken when fixing another bug.

Humdinger started documenting the Media preferences and found various settings which either did not seem to work, or no one could explain what they were supposed to do. Rather than documenting, it was more appropriate to simply remove them.

Drivers

waddlesplash fixed some issues in the XHCI driver, as well as some locking problems in the USB stack (crashed USB devices can no longer prevent your apps from exiting).

waddlesplash also reworked the unicode handling in the USB driver to use libtextencoding, providing a more reliable result for USB devices using non-ASCII characters in their string descriptors.

korli fixed the radeon_hd driver to discover the BIOS size from info available in PCI bus registers, and also fixed the framebuffer and sdhci drivers to handle 64bit BAR registers (PCI ports using 64bit addresses), alongside other fixes related to PCI BAR handling in the intel_extreme driver.

Lt-Henry and korli fixed some compiler warnings in the ACPI thermal probes driver.

korli made adjustments to hardware detection in the HDA driver, making it work on more hardware.

rudolfc continues his work on the Intel video driver, slowly adding support for all the possible combinations of chipset generations and output ports (HDMI, DisplayPort, …). This also includes some rework of the EDID handling and the way drivers can either get the EDID info from the VESA code used to set up the splash screen, or scan for connected displays by themselves.

Interface Kit

waddlesplash changed the prototype for the BBitmap::ImportBits method. This method is an Haiku addition, but its parameters were not well specified, making it confusing to use. Instead of taking separate width and height as parameters, it now uses a BSize, which is more easily generated from a BRect without off-by-one errors.

libroot & kernel

waddleplash fixed the implementation of wcsxfrm, which was broken and caused some applications to crash; most notably GTK3 file panels, which were the impetus for investigating its problems.

waddlesplash downgraded an assertion in the new ConditionVariable code (which seems to happen rarely in some virtual machines) into a syslog print, closing some KDL tickets.

korli added the timespec_get function from the C11 standard. It returns the current time (same as real_time_clock_usec) as a timespec. It currently only handles UTC time.

ARM!

David Karoly ocntinues his work on the 32 bit ARM port. This also involves reworking the EFI bootloader for 32bit support, which led to some refactoring and cleanup in that part of the code. As a result, it is now possible to boot the 32bit version of Haiku on EFI-only 32bit machines (such as early Intel CPU based Apple hardware, as well as some x86 CPU tablets).

His work also includes fixes to the early boot management of the MMU and memory map and the way it is transferred from the bootloader to the kernel. This allows the kernel to boot a bit further than it did in the last few years, with some icons lighting up on the bootscreen!

Another change that was needed to get there is rework of the handling of “interrupt-cells” property in the FDT, which describes how interrupts descriptions should be handled. The initial version of this was written for RISC-V CPUs and ARM machines need a different layout, now the code is able to handle both cases.

David also provided various other cleanups and refactorings after discussion with other people reviewing the changes, making the EFI code overall a lot cleaner and easier to reuse for more architectures in the future.

After a short break (his last commit previously was in 2011), Oliver Ruiz Dorantes, who you may remember for his work on the Bluetooth stack, has started work on getting the ARM64 port up and running. A first commit was merged this month, with more to come as the remaining problems are discussed (with some choices to make as to which generations of hardware we want to and can reasonably support). kallisti5 joined the fun with some work on the early debug console to help see the first output form the kernel in that still new and fresh port.

(Out-of-tree) contract work

In addition to last month’s “in-tree” work detailed above, waddlesplash put in a bunch more time on “Xlibe” (the X11 compatibility layer) and the nascent GTK3 port based on it. X512 submitted a pull request with some changes to get WINE’s X11 frontend working, which waddlesplash merged part of and fleshed out the rest of. Further implemented last month was basic X11 multithreading support, window property fixes, pointer-querying fixes, window stacking & restacking support (not “stack & tile” but rather sub-window ordering), window modality, window tree querying, root window identification, window border appearances (or lack thereof), pointer grabs, window resize fixes, text copy & paste (and a skeleton for implementing more copy & paste formats in the future), and a bunch of performance and memory leak fixes.

After all that work, GTK3 worked “well enough” that it seemed ready for general consumption (or at least testing), so waddlesplash committed the necessary changes to HaikuPorts for Xlibe to be packaged, and then GTK3, and then finally the first GTK3 application: Inkscape. Already, GIMP has followed closely on its tail thanks to 3dEyes (with some quick fixes to Xlibe done by waddlesplash for it), and more GTK3 applications are sure to follow once the HaikuPorts team gets caught up to speed on things.

You can find screenshots on the forums of both GIMP and Inkscape running on Haiku. With that, waddlesplash has deemed the “GTK3 porting adventure” complete, and has returned to development work on Haiku’s core for this coming month.

(waddlesplash also did a few other minor bug-fixes here and there in HaikuPorts last month: fixing crashes in PhotoGrabber, merging some patchsets for SDL2, and cleaning up some other X11 recipes related to the Xlibe work.)

That’s all, folks!

According to our roadmap, we have another beta release scheduled for just around the corner. waddlesplash (and hopefully the rest of the development team) intends to work on things related to this in the coming month: system stabilization, regression fixing, etc. With the additions of some pretty significant ported software, like QtWebEngine (Chromium), now GTK3 applications (GIMP, Inkscape, etc.), and quite soon WINE should be generally available, this next release is shaping up to be Haiku’s biggest one yet, and quite the jump from the last beta only last year.

Thanks once again to all of Haiku’s supporters, and our wonderful community! We could not do all this without you.

See you next month!