admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC-2.md: §17.4 framebuffer physics -- confirm still not ripe, correct its real prerequisite

Browse Source 
Live console/framebuffer stack has zero dirty-region or heat/decay instrumentation (grepped framebuffer.c/vt100.c/console.c). True prerequisite is item 1.11 (dirty-event granularity), still unstarted, not 'the framebuffer work' generally, which has since shipped. Left open.
This commit is contained in:
Robert Allan James
2026-08-13 10:22:55 -04:00
parent bb39012e55
commit c9710093ae
1 changed files with 17 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-2.md
+17
View File
@@ -302,6 +302,23 @@ and recorded.
- [ ] **§17.4 — the framebuffer utility's internal heat/decay dynamics are undesigned.**
Explicitly "Open, deferred": not a Stadium patron, but what physics (if any) governs it
internally was never designed. Not blocking anything.
> **CHECKED 2026-08-13, still correctly not ripe — precondition refined, item left open.**
> The actual FABRIC.md text (end of §17.5, not really §17.4 — that section number is a
> loose reference to the same "OPEN, deferred" paragraph) is explicit: "What those
> dynamics are is a question for when the framebuffer work actually happens... it should
> not be designed speculatively now." The console/framebuffer work (item 4.3/4.4 series)
> has since substantially shipped and is live, which looks at first glance like that
> precondition is now met. It isn't: grepped `src/starkernel/hal/framebuffer.c`,
> `vt100.c`, `console.c` (1,800 lines total) for `heat`/`decay`/`dirty` — zero hits. Every
> write is immediate-mode (`fb_scroll_rows()`, `fb_scroll_rect()`, direct glyph blits at
> the point of writing); there is no damage list, no dirty-region tracking, nothing a
> per-region heat/decay scheme would even attach to yet. That's consistent with Section
> A's item 1.11 (dirty-event granularity) still being unstarted — this item's true
> prerequisite is 1.11, not "the framebuffer work" in general as originally framed here.
> Designing framebuffer-internal physics before the dirty-event mechanism they'd govern
> exists would be exactly the speculative work FABRIC.md warns against. Left open, framing
> corrected: blocked on item 1.11, not merely deferred.
- [x] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical
message still fits in one cell" was never done — item 3.1's own done-note confirmed no
message-patron struct existed yet at the time. This is now checkable: item 4.2 built