NootedGreen.kext is on air! It's a long long road to complete..

[Stezza88]

Still have to commit and push and still I have BLACKSCREEN with dp0, need to test dp1 but should be...

 

-v keepsyms=1 debug=0x100 IGLogLevel=8 -NGreenDebug -liludbg liludump=140 ngreen-dmc=adlp -allow3d -disablegfxfirmware -ngreenfullmtldyld -ngreenfullmtlcore -ngreendp0 -ngreenexp ngreenV142=3 -ngreenV142diag2d ngreenV130=2 -ngreenv60 -ngreenV187off

 

The black screen at ~10s is eliminated. Here's the complete fix summary:

 

Patch    What it fixes
V97P    Clears bit16 in pending TRANS_DDI_FUNC_CTL so paramsFbCompare never triggers a full modeset
V97C    Aligns pending TRANS_CONF with live HW value so no spurious pipe update
V98    Keeps MAX_LINK_RATE=0x1e (HBR3) so Apple computes correct linkSymbolClock=810MHz M/N ratios
V99    Clears LINK_STATUS_UPDATED (DPCD[0x204] bit7) so the HDCP-triggered spurious IRQ_HPD doesn't cause checkLinkStatus to tear down the display

Lilu_1.7.2_23.6.txt fb-adlp.log

Edited May 5 by Stezza88

[Stezza88]

Saw the cursor with dp0 in dmc=adlp ... things will never be the sameeeeee

[Stezza88]

Again full black screen..... grrrr

[jalavoui]

read what i wrote about ghidra in git

 

add some of your frameb code to nblue and test or copy from

u lack some important parts

Edited May 6 by jalavoui

[Stezza88]

I will do it.. now i'm at work...

[Stezza88]

23 hours ago, jalavoui said:

read what i wrote about ghidra in git

 

add some of your frameb code to nblue and test or copy from

u lack some important parts

 

You are so big... wait for big fixes!!

[Stezza88]

.

Edited May 7 by Stezza88

[Stezza88]

* Paired with latest nootedbliue differences

boot args used now to test : -v keepsyms=1 debug=0x100 IGLogLevel=8 -NGreenDebug -liludbg liludump=200 ngreen-dmc=adlp -allow3d -disablegfxfirmware -ngreenfullmtldyld -ngreenfullmtlcore -ngreendp0 -ngreenexp -ngreenv60

 

ngreen-dmc=adlp : aggressive init
ngreen-dmc=skip : safest init

ngreen-dmc=tgl : untested aggressive init
ngreen-dmc=icl : untested init

 

still not sufficient

Edited May 7 by Stezza88

[Stezza88]

* Reached hd cursor + black screen with *ngreen-dmc=adlp* initialization

fb-adlpp-dp0.log Lilu_1.7.2_23.6.txt

 

Critical find: validateDisplayMode returns 0xe00002c2 (kIOReturnBadArgument) 3 times.

Edited May 7 by Stezza88

[jalavoui]

did u test frameb only mode?

 

logs are the same. why no screen?

 

only diff in params is cause ure lucky to have 4 lines so

2026-05-07 22:27:18.999951+0200  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 9084 ][SetupParams         ]           TRANS_DDI_FUNC_CTL = 0x8a010106
 

while i got

2026-05-06 19:27:48.252977+0100  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 9084 ][SetupParams         ]           TRANS_DDI_FUNC_CTL = 0x8a000102
 

nvm u still using full of junk code...

 

here's a sample open your log and type to filter

then do the same on this log

x.log.zip

 

why junk code ???

Edited May 7 by jalavoui

[Stezza88]

5 minutes ago, jalavoui said:

did u test frameb only mode?

 

Now I have the complete diagnosis. Here's what the logs reveal:

---

Root cause: two separate issues

dp0 (-ngreendp0, HD cursor, black screen)

WindowServer does fully initialize — kIOWindowServerActiveAttribute = 0x1 is set on FB0 at 22:27:19.531. The hardware cursor is driven correctly (HD cursor). But:

V76[5]: READ px[0]=0x0 px[512]=0x0 px[1023]=0x0  phys=0x7e457f000

PLANE_SURF is physically empty. WindowServer renders to the CPU compositing aperture (getScanRegionInfo: vramOffset=0x41200000), but the display hardware scans from SURF 0x412a2000 → physical 0x7e457f000 — a different physical address. Content is written to one place, display reads from another → black primary plane. Cursor is a separate plane unaffected.

Secondary issue: PSR2_CTL=0x4811 (bit 0 = PSR2 enabled). While PSR_STATUS=0x0 at T+10s (not yet in self-refresh), PSR2 being active on ADL-P with an ICL driver is a time-bomb.

dp1 (-ngreendp1, raw cursor)

V187 stubs AccessComplete to xor eax,eax / ret. This kills the "FB Ready" surface-flip signal. With DisplayPipeSupported=1, WindowServer enters the GPU display pipe wait loop, never gets the signal, watchdogd kills it → only the EFI boot cursor (raw) remains. Exactly what the V78 comment describes.

---

Immediate diagnostic step

Add -ngreenv88 to boot args (V60 experimental already active via -ngreenexp). V88 fills SURF's physical pages directly with red/green/blue/white bands via GGTT PTE lookup, bypassing the aperture entirely. If you see color bands → scan-out path works, aperture mismatch confirmed. If still black → deeper issue with PLANE_SURF itself.

---

What needs fixing (dp0 path)

The IOFramebuffer aperture maps GPU VA 0x41200000 but PLANE_SURF points to GPU VA 0x412a2000 (= aperture + 0xa2000). Either:

• A hook on the aperture/mode-set to remap SURF to the aperture physical pages, or
• Set the IOFramebuffer backing to match the already-allocated SURF

Also worth disabling PSR2 preemptively — add a write of 0 to EDP_PSR2_CTL (0x60900) in the DMC post-load code (after the ADL-P blob is loaded, before the original runs).

Edited May 7 by Stezza88

[Stezza88]

16 minutes ago, jalavoui said:

did u test frameb only mode?

 

logs are the same. why no screen?

 

only diff in params is cause ure lucky to have 4 lines so

2026-05-07 22:27:18.999951+0200  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 9084 ][SetupParams         ]           TRANS_DDI_FUNC_CTL = 0x8a010106
 

while i got

2026-05-06 19:27:48.252977+0100  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 9084 ][SetupParams         ]           TRANS_DDI_FUNC_CTL = 0x8a000102
 

nvm u still using full of junk code...

 

I need this junk AT THE MOMENT

[jalavoui]

k i gave u a tip go fix powerwell + whatever happens

[Stezza88]

26 minutes ago, jalavoui said:

did u test frameb only mode?

 

logs are the same. why no screen?

 

only diff in params is cause ure lucky to have 4 lines so

2026-05-07 22:27:18.999951+0200  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 9084 ][SetupParams         ]           TRANS_DDI_FUNC_CTL = 0x8a010106
 

while i got

2026-05-06 19:27:48.252977+0100  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 9084 ][SetupParams         ]           TRANS_DDI_FUNC_CTL = 0x8a000102
 

nvm u still using full of junk code...

 

here's a sample open your log and type to filter

then do the same on this log

x.log.zip 208.69 kB · 0 downloads

 

why junk code ???

 

I'm fixing this now

 

 

The friend's TRANS_DDI_FUNC_CTL analysis confirms the display hardware setup is correct — it's purely 4-lane vs 2-lane encoding (bits [3:1] = 0b011 = 4, plus a 4-lane flag at bit 16). Not the problem.

 

PSR2 is the smoking gun: it has the panel locked in self-refresh (showing the initial black frame), cursor updates flow through a separate selective-update path, main plane content never propagates.

Edited May 7 by Stezza88

[Stezza88]

Crucial data. The V76 diagnostic shows px[0]=0x0 px[512]=0x0 px[1023]=0x0 — the framebuffer memory is all zeros. Also, PWR_WELL=0x405 at tick 3 and 30, needing V104P to restore to 0x5405 each time.

Edited May 7 by Stezza88

[Stezza88]

Two fixes in this session:

1. V183.PGE — PG display well REQ bits now written to CTL1 (0x45400) instead of CTL2 (0x45404). The fb log confirmed it fired: en=1 mask=0x2a ctl1: 0x401->0x42b, and PLANE_SURF eventually reached 0x412be000 (display fully initialized this time).

2. V68 — Scheduler error 0x7b is now cleared unconditionally on iter 1. Previously it was blocked by the v60Aggressive gate (required -ngreenv60rw). That error was sitting in schedBase+0x0C blocking all GPU submissions → no pixels rendered.

After the next boot, look for in Lilu log:

• V68: early sched clear err=0x7b->0x0 flag=0x0 — confirms the clear fired
• V68: iter5 sched[0x0C]=0x0 — confirms it stayed cleared
• V76[5]: px[0]=0x... — any non-zero value means GPU rendered something

See ya when I return from work... power well fixed and whatever happens happened

fb-adlpp-dp0.log Lilu_1.7.2_23.6.txt

Edited May 8 by Stezza88

[Stezza88]

At the end, i will perform "a clean code check" for every method, one by one, step by step to perform :

- transform hard coded behaviours in a "to be extended by devs library"
- check junk
- preserve isrealTGL, !isrealTGL working

Edited May 8 by Stezza88

[jalavoui]

maybe no pwell logs cause of your 

void Gen11::hwSetPowerWellStatePGE(void *that, bool param_1, uint param_2)

but i think ai eat code as compared with apple code. review or keep if works

 

get rid of old functions with getMember<void *>(that, 0x90) = ccont; use from nblue

 

now that u use osinfo get rid of old patches in LookupPatchPlus const patches[] = {// tgl debug kext

 

disable functions that u dont call. i got bugs cause of keeping them. if a function type is uint32 and u set uint64 code will never work

 

dont see many bugs. hope u get this done soon

 

ah yes use the new nblue kext load logic as u miss base params for all kexts

 

funny thing ai also doesnt like backlight enab. i got it disabled in nblue but at some point we need to check apple logic as the code is used a lot everywhere

 

this mean 4 ports trainned

2026-05-08 00:50:04.131322+0200  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][AUX       ][AppleIntelPortHAL.cpp    : 1591 ][runAUXCommand       ]     RD address = 0x00202, data size = 2, cmd = 0x90020201, ddi = 0
2026-05-08 00:50:04.131604+0200  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][AUX       ][AppleIntelPortHAL.cpp    : 1762 ][runAUXCommand       ]     Data = 0x77 0x77 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 

 

0x77 + 0x77 -> 4 lines ok

0x33 + 0x77 -> 2 lines ok

 

idk how to adress this as if u force link training with hwreg=1 will link train fail ?

anyway this is not need for now - its next stage

just get frameb show a working screen

Edited May 8 by jalavoui

[Stezza88]

From your friend's feedback:

1. AppleIntelPlaneinit return type fixed: uint8_t → uint64_t in both .hpp and .cpp. ABI bug — the original function returns 64-bit; truncating to 8-bit could corrupt the caller's return value.

2. 5 redundant ccont-only hooks removed from RouteRequestPlus and their function bodies deleted:

   • disableScaler (getMember 0x28)
   • enablePlane (getMember 0x90)
   • programPipeScaler (getMember 0x28)
   • AppleIntelPlaneupdateRegisterCache (getMember 0x90)
   • AppleIntelScalerupdateRegisterCache (getMember 0x28)

   These are now handled by AppleIntelPlaneinit/AppleIntelScalerinit which already set ccont (matching nblue's approach).

3. f2d patch removed from tgl debug kext — getOSInformation hook sets pipe/port/fb counts directly; binary patches are redundant.

4. Dead probeF2Patch block removed (was dead reference code).

5. getMember<void *>(intelAccelerator, 0x90) = ccont removed from wrapPavpSessionCallback.

Black screen fix: 6. V105 blanking-pedestal detection fixed: The gamma LUT was stuck at 0x8020080 (Apple's blanking pedestal — R=G=B=128/1023 ≈ 12.5% gray, making everything appear black). The old check if (g128 == 0) never triggered because the pedestal is non-zero. New check compares entries 0 and 128 — if they're equal (constant LUT = blanking state), it writes the linear pass-through LUT. Same fix applied to both V105 (periodic) and V105B (V79 path).

[Stezza88]

The panic root cause: AppleIntelPlane::updateRegisterCache is called from setupBootDisplay → hwUpdateRegCache before AppleIntelPlaneinit ever runs, so field 0x90 (the register access manager) is NULL → ReadRegister32(this=NULL) crashes at offset 0x60.

Both updateRegisterCache hooks are restored. The three that were correctly removed (enablePlane, disableScaler, programPipeScaler) stay gone — they ran only after init, so their ccont fixup was truly redundant. The updateRegisterCache hooks run in a pre-init code path and are load-bearing.

[jalavoui]

undefined8 __thiscall AppleIntelPlane::init(AppleIntelPlane *this,IGPlaneID param_1)

this should be uint64_t as ai says. maybe this bugs call maybe not

anyway this is a sample of things that as today i still do wrong...

 

funny ai it understood my ccount patches - only where need!

 

those kp is cause u dont have same ccount functions as nblue - go copy from

 

ask ai to verify inside params of active declared functions. e.g funct xxx(AppleIntelBaseController *this,uint param_1)

i might have defined this wrong as xxx(AppleIntelBaseController *this,uint8 param_1)

 

found one in nblue gonna change

bool Gen11::AppleIntelFramebufferinit(void *frame,void *cont,uint32_t param_2)

to

undefined4 __thiscall
AppleIntelFramebuffer::init
          (AppleIntelFramebuffer *this,AppleIntelBaseController *param_1,uint param_2)

here undefined4 is uint32

 

omg undefined8 __thiscall AppleIntelPlane::init(AppleIntelPlane *this,IGPlaneID param_1)

IGPlaneID not uint8 at min uint32

 

same for scaler

gonna commit changes to github

done and tested - it as no visible bugs but

 

am i 100% sure?

no cause for demangling this functions depends on the decompiler, idra pro, bninja, ghidra they dont resolve same way

anyway as u can see old definitions also worked

maybe cause functions are using small values and uint8 is ok to handle function uint32 values but

it's always good idea to pay attention to this

 

@Visual Ehrmanntraut

Visual if u read this mind elaborate on this issue?

Edited May 8 by jalavoui

[Stezza88]

All five hooks are fully restored with their declarations, member variables, and function bodies. The situation is now clear:

• The friend's advice to remove these hooks is correct in principle — they're redundant once AppleIntelPlaneinit/AppleIntelScalerinit run first
• But those init hooks are commented out in kern_genx.cpp:75-76, so fields 0x28/0x90 are never set at object creation
• Result: every Plane/Scaler entry point (disableScaler, enablePlane, programPipeScaler, updateRegisterCache) that calls ReadRegister32 panics with this=NULL

The permanent fix is to uncomment the init hooks in kern_genx.cpp — once AppleIntelPlaneinit and AppleIntelScalerinit are active and set the fields correctly, all five redundant hooks can be safely removed again. But that needs a separate test pass.

[Stezza88]

 

Root Cause: Cursor on Black — Confirmed

Your bet is correct. The black screen is caused by -ngreendp0 breaking both GPU and CPU compositing simultaneously through a surface migration that neither path can bridge.

The Exact Chain

T=18:41:55.864 — WindowServer starts, setDisplayMode fires, setupScanoutMemory sets FB0: Using aperture memory — surface is in GGTT aperture range, CPU-accessible via BAR2.

T=18:41:56.083 — WindowServer signals fully active via kIOWindowServerActiveAttribute = 0x3.

T=18:41:56.109 — setDisplayMode re-fires, setupScanoutMemory immediately does:

FB0: Migrating from aperture memory
FB0: Using non-aperture memory

Then PLANE_SURF 0 → 0x412be000 is committed to hardware (V76[5]: GGTT page 0x412be, phys 0x7e1536000).

This is the moment everything breaks. 0x412be is GGTT page 266174. A 256MB BAR2 aperture covers only pages 0–65535. The surface is now ~4× beyond the aperture — the CPU compositor can never reach it.

Both Paths Are Dead

GPU display pipe (the path -ngreendp0 is supposed to disable):

• DisplayPipeSupported=0 set by V78 boot-arg → submitBlit mode=1 (no-op, no GPU commands)
• IOAccelDisplayPipe is still alive and fires transactions into the kernel
• Zero GPU rendering → AccessComplete (V187) stubbed → transaction stamp 9 never advances
• Result: IOAccelDisplayPipe (fbindex=0,1,2) transaction stamp index 9 time out every ~5s from T+18:42:03 onward

CPU compositing path (what -ngreendp0 is supposed to enable):

• WindowServer enters CPU compositing mode (never opens IOAccelDisplayPipeUserClient2 — confirmed isOpen=0 from T+10s to T+120s)
• Writes pixels linearly to the BAR2 aperture (GGTT offsets 0x0–0xFFF000)
• Display hardware scans PLANE_SURF=0x412be000 (GGTT page 0x412be, non-aperture)
• The two addresses never overlap → surface stays zero-initialized → black

Hardware cursor: Set up at controller init via hwUpdateCursorMemory / hwSetupCursorMemory, physical address 0x4004000000 — completely independent of GGTT or compositing. Always visible. → Cursor on black.

The Triggering Event

It is precisely kIOWindowServerActiveAttribute = 0x3 that fires setupScanoutMemory's migration branch. Without that attribute change, the surface stays in aperture memory. With it, the driver runs its normal "WS is up → hand off to GPU" migration, but with DisplayPipeSupported=0 that hand-off goes nowhere.

The Fix

Hook setupScanoutMemory (or the setDisplayMode/getAttribute path that drives it) and block the aperture→non-aperture migration when isDisplayPipeForceDisabled() is true. Keep the surface in aperture memory so the CPU compositor can write to it. The plane must also stay linear (PLANE_CTL tiling=0) for CPU writes to scanout correctly — which it already is during the aperture phase (CTL=0x94000008, tiling=0) and only becomes Y-tiled after migration.

The V99R patches (X→Y tiling) only fire at hwRegsNeedUpdate time, which is post-migration. If migration is suppressed, V99R never fires for the non-aperture allocation and the plane correctly stays linear throughout the CPU compositing lifetime.

Summary Table

	GPU pipe (DisplayPipeSupported=1)	CPU compositing (DisplayPipeSupported=0, -ngreendp0)
Surface location	Non-aperture (0x412be000)	Non-aperture (0x412be000) — broken
Who writes pixels	GPU via GGTT (can reach 0x412be000)	CPU via BAR2 (can't reach 0x412be000)
Blocker	AccessComplete V187 stub crashes WS	Surface outside CPU aperture
Visual result	WS crash → KP	Black screen
Cursor	Visible	Visible

The -ngreendp0 path was designed for CPU compositing but doesn't prevent the surface from migrating to non-aperture memory. The Intel driver unconditionally migrates on WS activation regardless of DisplayPipeSupported. NootedGreen needs to intercept that migration and suppress it when in dp0 mode.

fb-adlpp-dp0.log x.log.zip Lilu_1.7.2_23.6.txt

Edited May 8 by Stezza88

[Stezza88]

BIG PROGRESS : FLASH BRIEF ORIGINAL COLOR ON DP0

 

IT'S AN HALF MIRACLE, NEVER HAPPENED ON DP0

 

SYSTEM IS STABLE NOT CRASHING LIKE WAS IN DP1

 

THIS IS CLEARLY A MILESTONE

fb-adlpp-dp0.log x.log.zip Lilu_1.7.2_23.6.txt

 

This is huge — the aperture fix is working. The brief real-content flash is the CPU compositor writing to GGTT[0] and the display correctly reading it. The "red horizontal bar" is V88's color-band fill now hitting the aperture surface (which it couldn't reach before). Let me read the new logs.

Edited May 8 by Stezza88

[Stezza88]

Why "blocked at first frame": After setupScanoutMemory migrates, WindowServer updates its write target to the non-aperture physical pages (~0x7fc000000). V99S kept PLANE_SURF=0x0 (display reads GGTT[0..3999] → old physical pages < 0x40000000), but WS was compositing to completely different physical pages — divergence → black screen with frozen first frame.

Three fixes in this build:

1. V99G (new, the main fix): On the first non-aperture SURF interception, copies 4000 GGTT PTEs from the non-aperture surface (GGTT[0x412be..]) down to GGTT[0..3999], then flushes GGTT TLB. After this, SURF=0x0 scans the same physical pages WS is writing to → display shows live WS content continuously.

2. V55 dp0 guard: Skips registerService() on IOAccelDisplayPipeUserClient2 when -ngreendp0 is active. This prevents the display pipe from reaching state=0x1e, stopping the stamp index 9 time out → GPURestartSignaled loop every 5.4s that was periodically disrupting the compositor.

3. V88 dp0 guard: Skips the entire color-band fill in dp0 mode. Prevents the V88[5] plane toggle from briefly arming with the wrong SURF address (the hardware register echo of the pre-V99S write).

Expected log to look for after this boot: V99G: GGTT[0..3999] <- GGTT[0x412be..] remapped=4000 skip=0 — that's the remap completing. After that, SURF=0x0 should display live WS content.