@bsek please let me know if those commits break anything in the raspi gfx driver for you

I'll try to test it later today

I hope you don't ming I shime in as well given that I have the cocoa driver I'm building that is impacted as well. The refactor (

7561a979

, splitting the monolithic

Hidd_Gfx

into

Hidd_Gfx

+

Hidd_Display

+

Hidd_DMEnum

) was clean to port to from a downstream driver's side. SDL was an excellent template. The mechanical part: • `CreateObject`and`Show`move from`Hidd_Gfx`onto a new`Hidd_Display`subclass. • Mode tags rename:`aHidd_Gfx_{PixFmt,Sync}Tags`to`aHidd_DMEnum_{PixFmt,Sync}Tags`. • Driver creates a`CLID_Hidd_Display`subclass instance with`aHidd_Display_GfxHidd`+`aHidd_Display_ModeTags`, and`Root::Get`answers`aoHidd_Gfx_DisplayDefault`. Two things that cost real debugging time, interesting for anyone with an out-of-tree or host-window driver: 1. The soft-cursor framebuffer wrapping means the bitmap object passed to

Display::Show

is not the one intuition actually composites into and raises`UpdateRect` on. A driver that scans out one framebuffer (ours uploads a single buffer to a Metal window, conceptually like a real fb) has to track the unwrapped bitmap, not Show's argument. 2.

UpdateRect

is now routed through the bitmap class for many bitmaps, not just the screen, including 32x32 icon image bitmaps. Those carry`modeid=0`, which is *not*`vHidd_ModeID_Invalid`, so a ModeID-based test wrongly accepts them. The correct gate is`aHidd_BitMap_Displayable`. This produced some black artifacts after the merge that were hard to fix (for me at least). Overal great work, it'"s the right direction and it forced me to redesign some parts of my architecure but the result is a more stable driver now, I had some lost pixels here and there because of thzt. I hope it's solved now. Separately, the

stdc.library

0.47 to 0.48 bump in the same batch is an ABI break (LVO/struct + the program startup/teardown glue): every pre-bump userland binary SIGSEGVs in

__stdc_program_end

. That is correct for an ABI bump, but the blast radius is the whole userland, so a coordinated rebuild is mandatory. The version bump is the only signal. Rebuilding everything takes 2-3 hours on a macbook air M5... thanks.

@John Knipper 2-3 hours sounds too long, do you re-build the toolchain every time?

Let me check again exactly how long it's taking...

only takes me that long on x86 doing a full clean build

Actually you're right, the whole kernel set,

compiler-stdc/stdcio/posixc

, linklibs, and most

workbench-libs, workbench-c

(the ~119 commands) and the Wanderer/Zune/datatypes set takes about an error I would say, my bad.