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

[Stezza88]

Now the friend's CRTCParams analysis — 299 use sites is a clear pattern. Here's the call hierarchy and what each one does:

Builder layer (populates the struct):

• SetupParams — top-level, calls all the others
• SetupTimings — TRANS_HTOTAL/HBLANK/HSYNC/VTOTAL/VBLANK/VSYNC (transcoder timings)
• SetupDPSSTTimings / SetupDPTimings / SetupMSTDPTimings — DP M/N values, link bandwidth
• setupDSCEngineParams (3 sites!) — DSC compression slice config
• setupPipeScaler (2 sites) — PS_CTRL / PS_WIN_POS / PS_WIN_SZ
• setupPipeWatermarks — DBUF allocation per plane
• hwCRTCToIODetailedTiming... / hwGetCRTC — round-trip conversion

Comparator (decides if HW reprogram needed):

• paramsSurfCompare (2 sites — old vs new)
• hwRegsNeedUpdate — gates partial vs full modeset

Applier (writes to MMIO):

• hwSetMode
• hwSetupMemory

Top fragmentation suspects ranked by likely contribution to "linear visible / X-tile black + 8-row repeating pattern":

1. setupDSCEngineParams × 3 calls — 🚨 strongest suspect. DSC = Display Stream Compression. If Apple enables DSC for our panel (Display 12 default behavior) but our 2560×1600 RPL-P panel doesn't actually use DSC (or uses different slice config than Display 13 expects), the decompressor produces stripe-patterned garbage that looks identical to fragmentation/repetition. Slice height = 8 rows would explain the 8-row repeat.

2. setupPipeScaler — if scaler is enabled and configured for non-1:1, image gets stretched/repeated.

3. setupPipeWatermarks / DBUF — wrong DBUF block allocation = plane reads from wrong byte ranges.

4. setupOptimalLaneCount + DP M/N mismatch — wrong M/N = wrong pixels-per-symbol = repeating offset per scanline.

Concrete next step: hook one of these (start with setupDSCEngineParams since DSC slices match the symptom) and dump the CRTCParams it builds. If DSC is being enabled when it shouldn't, force-disable it at the param level — exactly the friend's "fix it in Apple's code, not in MMIO" pattern.

Want me to plan the setupDSCEngineParams interceptor (logger first, then conditional disable on !isRealTGL)?

[Stezza88]

uint8_t Gen11::hwRegsNeedUpdate
		  (void *that,void *param_1,
		   void *param_2,void *param_3,void *param_4,
		   void *param_5)
{
	// IDA (hwSetMode + hwRegsNeedUpdate) confirms param_3 is the pending CRTCParams
	// built by SetupParams. CRTCParams+0x04 is TRANS_DDI_FUNC_CTL. On spoofed !TGL,
	// clear bit[16] before compare/apply so the full modeset path does not request
	// 0x8a010106 against an already-trained 0x8a000106 link.
	if (!NGreen::callback->isRealTGL && param_3) {
		auto *pending = reinterpret_cast<uint32_t *>(param_3);

		// V97P: clear bit[16] in TRANS_DDI_FUNC_CTL (offset +0x04).
		// Apple's SetupParams sets bit16 as a port-type flag; UEFI/HW never sets it.
		// Without this the DDI FUNC_CTL compare fires and triggers a full modeset
		// that disrupts the already-trained 4-lane eDP link → black screen.
		uint32_t &transDdi = pending[1]; // offset +0x04
		if (transDdi & (1u << 16)) {
			static int v97PCount = 0;
			if (v97PCount < 12) {
				v97PCount++;
				SYSLOG("ngreen", "V97P[%d]: CRTCParams TRANS_DDI_FUNC_CTL 0x%x -> 0x%x",
				       v97PCount, transDdi, transDdi & ~(1u << 16));
			}
			transDdi &= ~(1u << 16);
		}

		// V97C: align pending TRANS_CONF (offset +0x2C) with the live HW value.
		// paramsFbCompare logs "TRANS_CONF 0xc0000000->0xc0000024": HW has bits[5,2]
		// clear (UEFI default), Apple wants to set them (interlace/depth config).
		// Writing those bits to an active pipe causes a transient signal disruption
		// that sets the panel's DPCD InterLane Alignment Lost bit (0x202=0x80),
		// which checkLinkStatus detects ~10 s later and tears down the display.
		// Fix: replace the pending TRANS_CONF with the current HW register value so
		// paramsFbCompare sees no change and the partial pipe update is suppressed.
		// PIPE_CONF_A (= TRANS_CONF in ICL+) = 0x70008.
		// NOTE: 0x60008 is TRANS_HSYNC_A (horizontal sync timing) — do NOT use that.
		uint32_t &transConf = pending[11]; // offset +0x2C
		const uint32_t hwTransConf = NGreen::callback->readReg32(0x70008);
		if (transConf != hwTransConf) {
			static int v97CCount = 0;
			if (v97CCount < 12) {
				v97CCount++;
				SYSLOG("ngreen", "V97C[%d]: CRTCParams TRANS_CONF 0x%x -> HW 0x%x (suppressed pipe update)",
				       v97CCount, transConf, hwTransConf);
			}
			transConf = hwTransConf;
		}

		// V300: KILL DSC engine enable bits in CRTCParams.
		// Apple's setupDSCEngineParams (IDA __ZN24AppleIntelBaseController20setupDSCEngineParams...)
		// writes DSC engine select to CRTCParams[+0xE8] (0x40000000/0x60000000/0x70000000)
		// and joiner control to CRTCParams[+0xEC] (0x80008000/0x80000000) when the port
		// reports DSC support via DPCD. PIPE_DSS_CTL then activates the DSC decoder.
		// Our panel/WS write uncompressed pixels — DSC decoder running over uncompressed
		// data produces an 8-row striped pattern (DSC slice height = 8) which matches
		// our fragmentation/repetition symptom EXACTLY. Zeroing both fields here on
		// !isRealTGL disables the DSC engine at struct level (per friend's advice:
		// "fix in apple code, not MMIO") so PIPE_DSS_CTL is programmed = 0.
		// PPS_0..PPS_16 at +0x88..+0xB4 don't need clearing — they're inert without
		// the engine enable bits in +0xE8.
		uint32_t &dscEngine = pending[0xE8 / 4]; // offset +0xE8 = pending[58]
		uint32_t &dscJoiner = pending[0xEC / 4]; // offset +0xEC = pending[59]
		if (dscEngine || dscJoiner) {
			static int v300Count = 0;
			if (v300Count < 12) {
				v300Count++;
				SYSLOG("ngreen", "V300[%d]: CRTCParams DSC engine=0x%x joiner=0x%x -> 0,0 (DSC disabled)",
				       v300Count, dscEngine, dscJoiner);
			}
			dscEngine = 0;
			dscJoiner = 0;
		}
	}

	// Return the original result so that register reprogramming proceeds normally.
	// The lane count mismatch (4→2) that previously broke the display is now fixed
	// by the computeLaneCount hook forcing 4 lanes.  Without register updates, the
	// plane surface address and stride never get written, leaving the stale BIOS
	// framebuffer on screen (grey/black vertical bars with only cursor visible).
	return FunctionCast(hwRegsNeedUpdate, callback->ohwRegsNeedUpdate)(that, param_1, param_2, param_3, param_4, param_5);
}

 

22 minutes ago, jalavoui said:

u will end up finding a solution it's a matter of time. remenber that your display show signs of be alive

try those params analysys maybe u find something

 

tell ai stop alucinating with memory writes! that is not a fix. try fix origin not hack with mem writes

 

linux seems dsc not enabled

2024-10-23T18:27:18.191617+02:00 sgiammoript-Predator-PT14-51 kernel: i915 0000:00:02.0: [drm:print_ddi_port [i915]] Port A VBT info: CRT:0 DVI:0 HDMI:0 DP:1 eDP:1 DSI:0 DP++:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
is ai reading linux log ?

2024-10-23T18:27:18.193666+02:00 sgiammoript-Predator-PT14-51 kernel: i915 display info: has_dsc: yes
but not used in linux code. need confirmation

 

inside nblue info.plist in firmware folder  i set

but at least for my display it is not available. this set come from icl settings time

 

apple decides dsc in getDPCDInfo() verify if origin here as im not sure

we just total forgot frameb base settings. there are the ones from info.plist and also others in a apple function

 

hahaha I know you reacted like this

[Stezza88]

// V300 REVERTED — was a memory-write hack zeroing CRTCParams[+0xE8]/[+0xEC] to

// kill DSC engine select bits. Per jalavoui's feedback ("stop hacking memory

// writes, fix the origin not the destination"), DSC should be controlled at

// getDPCDInfo / Info.plist FeatureControl level, not patched after-the-fact in

// the CRTCParams struct. Our Info.plist already sets DSCSupport=0/DSCCapReporting=0

// (confirmed by fb.log "DSC supported: 0" / "DSC Caps Reporting enabled: 0"),

// so if Apple still calls setupDSCEngineParams the path is somewhere downstream

// that ignores FeatureControl — needs investigation at the origin function, not

// here. Linux on this hardware: VBT Port A DSC:0, link runs "DSC off" → DSC was

// likely a wrong hypothesis for the fragmentation symptom in the first place.

 

 

 

 

 

 

 

Got it — friend wants proper struct definitions for CRTCParams / PLANEPARAMS / SCALERPARAMS extracted from Ghidra, used as typed access instead of pending[N] raw offsets. Let me create a clean header capturing what we know from Ghidra so far. @jalavoui

Edited May 10 by Stezza88

[Stezza88]

 

State of the library improvement:

AppleIntelParams.hpp — new typed header with:

• AppleIntel::CRTCParams (12 named fields + 12 DSC PPS slots + DSC engine/joiner, all offsets verified via static_assert)
• AppleIntel::SCALERPARAMS (PS_CTRL / PS_WIN_POS / PS_WIN_SZ)
• AppleIntel::PLANEPARAMS forward declaration (TBD — friend removed it before export, needs Ghidra rebuild)

kern_gen11.cpp:6692-6726 — V97P/V97C refactored from pending[1] / pending[11] raw uint32_t indexing to params->TRANS_DDI_FUNC_CTL / params->TRANS_CONF named access. Build still passes — static_asserts confirm offsets are right.

What I need from you in Ghidra to flesh out the header:

1. CRTCParams full size + the _pad_30 gap (offsets 0x30 to 0x87) — open CRTCParams in Structure Editor, scroll past +0x2C TRANS_CONF, name any fields used by SetupTimings, SetupDPSSTTimings, setupPipeWatermarks.

2. The _pad_B8 gap (0xB8 to 0xE7) — between the PPS_16 slot and DSC engine — likely DSC slice config / bpp / line buffer params consumed by setupDSCEngineParams.

3. PLANEPARAMS — used by paramsSurfCompare(CRTCParams*, CRTCParams*, PLANEPARAMS*, PLANEPARAMS*). Decompiling that function will reveal which offsets are read. Plane fields likely include PLANE_CTL, PLANE_STRIDE, PLANE_SURF, PLANE_SIZE, PLANE_OFFSET, PLANE_POS.

4. SCALERPARAMS full size — friend said incomplete; check setupPipeScaler and AppleIntelScaler17syncScalerUpdate for offsets past +0x0C.

If you paste any of these from Ghidra (Structure Editor view or the decompiled function), I'll extend the header with verified fields + static_asserts, then we can hook the call sites cleanly without void * casts.

Edited May 11 by Stezza88

[Stezza88]

Check the file I provided...

 

This is only the init of the improvement..

Edited May 10 by Stezza88

[jalavoui]

ai good thinking - less alucination "needs investigation at the origin f"

what about initial hardware settings of getDPCDInfo() paired with apple static info.plist and apple global params function  AppleIntelBaseController::getFeatureControl()

 

and because i dont need ai alucinations final step is check linux lib header that i spend my time building so logic of linux can be used on apple code. i dont need ai guessing anything that doesnt exist on linux sources

 

don't grab from linux github cause ai doesnt know kernel makefile build params or paths. the lib already as relative paths + a header injection of default config on all headers. this wont compile but is fine for code check (ignoring some duplicate errors + compiler.h related extra calls)

#include "../../../../include/linux/aperture.h"
#include "../../../../include/linux/vt.h"
#include "../../../../include/drm/drm_atomic_helper.h"
#include "../../../../include/drm/drm_client.h"
#include "../../../../include/drm/drm_probe_helper.h"
#include "../../../../include/drm/intel/display_member.h"
#include "../../../../include/drm/intel/display_parent_interface.h"
#include "../../../../include/drm/intel/intel_pcode_regs.h"

can you check what are the platforms ai should use ? dont need all 

adlp as extra dma_mask idk how apple handles this

got some doubts about this logic

#define GEN8_FEATURES \

G75_FEATURES, \

GEN(8), \

.has_logical_ring_contexts = 1, \

.dma_mask_size = 39,

 

but keep descending shows: 

 

#define GEN7_FEATURES  \

GEN(7), \

.dma_mask_size = 40, \

static const struct intel_device_info tgl_info = {
	GEN12_FEATURES,
	PLATFORM(INTEL_TIGERLAKE),
	.platform_engine_mask =
		BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
};

static const struct intel_device_info adl_s_info = {
	GEN12_FEATURES,
	PLATFORM(INTEL_ALDERLAKE_S),
	.platform_engine_mask =
		BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
	.dma_mask_size = 39,
};

static const struct intel_device_info adl_p_info = {
	GEN12_FEATURES,
	PLATFORM(INTEL_ALDERLAKE_P),
	.platform_engine_mask =
		BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
	.__runtime.ppgtt_size = 48,
	.dma_mask_size = 39,
};

 

Edited May 10 by jalavoui

[Stezza88]

I'm using ghidra on mac

 

When i return from work i'll see

Edited May 11 by Stezza88

[Stezza88]

.

Edited May 11 by Stezza88

[Stezza88]

.

 

Edited May 11 by Stezza88

[Stezza88]

All improved

extract_apple_params.py

 

ghidra_seed_structs.h structsGFX.h

structsFB.h

AppleIntelParams.hpp

Edited May 11 by Stezza88

[Stezza88]

// CTL/STRIDE forces — MATCH LINUX. Linux i915 on this exact hardware uses:

// PLANE_CTL[12:10] = 100 (Y-tiled-legacy) per reg_dump.txt DSPACNTR=0x92001000

// PLANE_STRIDE = 0x50 (80 Y-tile units = 80*128B = 10240B/row = 2560*4bpp)

// Replaces the previous linear+0xa0 force (which matched bytes-per-row but

// interpreted X-tiled buffer bytes as linear → fragmentation). Y-tile interpretation

// of the same physical bytes is what Linux ships and what the panel expects.

// Gated on !isRealTGL (real TGL programs natively).

if (NGreen::callback && !NGreen::callback->isRealTGL) {

uint32_t hwTiling = (hwCtl >> 10) & 0x7;

if (hwTiling != 0x4) {

// Force tile bits[12:10] = 100 (Y-tiled-legacy)

uint32_t newCtl = (hwCtl & ~(0x7u << 10)) | (0x4u << 10);

NGreen::callback->writeReg32(0x70180, newCtl);

}

if (hwStride != 0x50) {

NGreen::callback->writeReg32(0x70188, 0x50);

}

}

force Y-tiled-legacy + STRIDE=0x50 instead of linear + 0xa0

x.log.zip fb.log

Edited May 11 by Stezza88

[Stezza88]

.

Edited May 11 by Stezza88

[Stezza88]

I'm learning so much... when I will study everything as bible we know I will become g.o.d.XD 

• Linear+0xa0 (current V99S force): correct only if buffer is linear in memory — but Apple's renderer makes X-tile. Under -ngreendp0 the CPU compositor writes linear bytes to BAR2, so this coincidentally works visually but fragments (per-row offset accumulates).
• Y-tile+0x50 (Linux): correct only if buffer is Y-tile — but Apple's allocator made X-tile → BLACK.
• X-tile+0x14 (Apple natural, no V99S): correct only if scanout reaches the buffer — but without dp0, V99G GGTT remap doesn't fire, so SURF=0 reads GGTT[0..] which Apple mapped to stolen memory (not BAR2 where WS writes) → BLACK.

Found two important things in the logs.

1. V99S[5..] shows pixel data IN the BAR2 aperture:

V99S[5]: ... tl=00bfbfbf ctr=00bfbfbf bar=00bfbfbf mid=00bfbfbf

0xBFBFBF = light gray. So WindowServer IS writing pixels to BAR2 aperture. Content exists.

2. V401 shows Apple's natural PLANEPARAMS:

NEW: CTL=0x94000408 tile=0x8 STRIDE=0x14 SURF=0x0

Apple programs PLANE_CTL bits[12:10]=001 = X-tiled (not Y-tiled). Our V99S force overrides to Y-tile (bits=100), but the actual buffer in memory is X-tile, not Y-tile.

That's why Y-tile force = black: Y-tile interpretation of an X-tiled buffer produces totally wrong byte mapping → empty/zero scanout → black.

Linux uses Y-tile because Linux's i915 GEM allocator allocates buffers Y-tiled. Apple's IOSurface allocator on this hardware allocates X-tiled (per Apple's CTL choice). The Linux reg_dump matches Linux's buffer layout. Apple's natural matches Apple's buffer layout.

[Stezza88]

SMOKING GUN FOUND. Read the values carefully:

• V400[1]: PS_PS_WIN_SZ=0x0, SEAM_EXCESS=0 — first call, scaler not yet configured
• V400[2..N]: PS_PS_WIN_SZ=0x3fff04f, SEAM_EXCESS=0x1 — scaler activated, with seam-excess flag set

Two findings:

1. Source is correct 2560×1600 (my decoder labeled W/H backwards — PIPE_SRCSZ=0x9ff063f is actually horizontal=0x9ff+1=2560, vertical=0x63f+1=1600 per Intel reg spec, not 1600×2560).

2. Apple is enabling "Seam joining scaler" on this single-pipe panel. From the setupPipeScaler disasm itself there's a literal log line "Seam joining scaler enabled\n" — and SEAM_EXCESS=1 confirms Apple set that bit. Seam joining is a dual-pipe feature where two pipes each handle ~half the screen + a shared overlap "seam" region. On a single-pipe 2560×1600 panel, this should NEVER be active.

When seam joining is enabled on a single pipe:

• Plane reads partial regions per scanout segment
• Per-row offsets accumulate (PIPE_SEAM_EXCESS adds overlap each line)
• Resulting pattern: same content stretches/repeats at horizontal slice boundaries

That matches your fragmentation/repetition symptom exactly.

The PS_PS_WIN_SZ=0x03FFF04F decoded with Intel's 13-bit-per-field convention is ~1024×80 — not a real scaler window, but the seam-mode encoding (overlap region sub-coordinates).

Want me to add a surgical fix in the V400 hook: clear PIPE_SEAM_EXCESS and zero PS_PS_WIN_SZ on !isRealTGL to disable seam joining? Read-only logger turns into a one-line fix — write back zero to those two CRTCParams fields after Apple's setupPipeScaler populates them, and let Apple's downstream code reprogram the pipe without the seam join.

Alternatively (more surgical): find where Apple decides to enable seam joining (probably a condition in setupPipeScaler or its caller) and disable it at the decision point. The disasm has a _gSysctlVariables[+0xD8] check — that might be the seam-joining feature toggle.

DEFINITIVE CONFIRMATION. Linux i915 on the exact same hardware reports:

bigjoiner: no, pipes: 0x0
pipe src: 2560x1600+0+0
pixel rate 785400

bigjoiner is i915's name for the same dual-pipe-joining feature Apple calls "Seam joining scaler". Linux says NO bigjoiner, NO pipe joining, single pipe for this panel. Apple is doing the opposite.

So the bug is unambiguous: Apple's TGL framebuffer driver wrongly enables seam-joining scaler for a panel that should run single-pipe. The fragmentation pattern is the direct visible result.

// CTL/STRIDE forces — MATCH APPLE'S NATURAL INTENT.

// V401 paramsSurfCompare logs prove Apple wants: CTL bits[12:10]=001 (X-tiled),

// STRIDE=0x14 (20 X-tile units = 10240B/row = 2560*4bpp). Apple's IOSurface

// allocator produces X-tiled physical buffers — Y-tile and linear forces both

// scan wrong bytes from an X-tile buffer. Match Apple = same tile mode as the

// buffer = correct scanout, IF the SURF address reaches the right pages

// (V99R[P]+V99G handle the SURF redirect / GGTT remap unconditionally).

//

// Gated on !isRealTGL. Real TGL programs natively.

if (NGreen::callback && !NGreen::callback->isRealTGL) {

uint32_t hwTiling = (hwCtl >> 10) & 0x7;

if (hwTiling != 0x1) {

// Force tile bits[12:10] = 001 (X-tiled)

uint32_t newCtl = (hwCtl & ~(0x7u << 10)) | (0x1u << 10);

NGreen::callback->writeReg32(0x70180, newCtl);

}

if (hwStride != 0x14) {

NGreen::callback->writeReg32(0x70188, 0x14);

}

}

[Stezza88]

STRIDE field semantics depend on CTL tiling:

• Linear: STRIDE = bytes/64 cachelines → 0xa0 = 160×64 = 10240 B/row ✓
• X-tiled: STRIDE = X-tile-units (one tile = 512B wide) → 0x14 = 20×512 = 10240 B/row ✓
• Y-tiled: STRIDE = Y-tile-units (one tile = 128B wide) → 0x50 = 80×128 = 10240 B/row ✓

Tile force	Interpretation of linear physical bytes	Result
Linear + 0xa0	Read bytes as linear, 10240B/row	Matches buffer reality → visible (fragmentation from a SEPARATE issue)
X-tile + 0x14	Read linear bytes thinking they're in X-tile 4KB-block layout	Wrong byte mapping → broken/black
Y-tile + 0x50	Read linear bytes thinking they're in Y-tile 4KB-block layout	Wrong byte mapping → broken/black

Edited May 11 by Stezza88

[Stezza88]

The fragmentation under linear is NOT a tile-mode issue. It's some other linear-buffer-layout problem. Most likely candidates:

1. GGTT remap target wrong — V99G copies GGTT[srcPage..srcPage+3999] → GGTT[0..3999]. If WS writes to pages OUTSIDE that range (because IOSurface allocates 64MB = 16384 pages and the scanout offset within that isn't srcPage), display reads stale.
2. Per-row stride mismatch — Apple's actual IOSurface row stride could be padded (e.g., 16384 B/row for 4-page alignment) instead of 10240. Display at stride 0xa0 would then offset 6144 bytes per row → repeating pattern (exactly what fragmentation looks like).
3. Buffer base offset — pixel data might start at offset N within the first page, not at page boundary.

Without -ngreendp0 (default or -ngreendp1😞

• Apple's native IOFramebuffer scanout path runs.
• Apple's IOSurface allocator expects the GPU/Metal pipeline to render X-tiled content (per the X-tile CTL).
• But on our RPL spoofed as TGL, Metal isn't fully initialized — -ngreenfullmtlcore / -ngreenfullmtl / the various Stage-3 NULL stubs are evidence Metal hits NULL derefs and falls back.
• With Metal broken/partial, the GPU never tile-encodes pixels. WS falls back to CPU writes that are LINEAR.
• The "X-tiled" buffer Apple allocated stays mostly zeroed; whatever pixel data lands there is from CPU writes (linear).
• V99S linear force matches that reality → visible (possibly fragmented).

With -ngreendp0:

• WS explicitly uses CPU compositor (no GPU rendering attempted) → writes linear via BAR2.
• V99R[P]+V99G remap GGTT to where WS writes.
• V99S linear force matches → visible (also fragmented).

[Stezza88]

I go in spiritual retirement to study all of this {censored} we did.

Bye see you soon 😜

Edited May 11 by Stezza88

[Stezza88]

With WEG Coexistence arg I booted!!!! Only FB!!! @jalavouiiiiiiiiiiiiii

Use forked one I put in first page!

Soon I put my lilu and weg forked sources!!!!!  Exceptionaaaaaaal

 

-ngwegcoex

 

-v keepsyms=1 debug=0x100 IGLogLevel=8 -ngreentglfb -NGreenDebug -liludbg liludump=500 -wegdbg -ngwegcoex ngreen-dmc=adlp -ngreenv189

 

Lilu_1.7.2_23.6.txt fb.log x.zip

Edited May 11 by Stezza88

[Stezza88]

FB+GFX still not working , all frozen at first Apple Original flash brief.

Edited May 11 by Stezza88

[Stezza88]

2 long years ... tell me ioreg logs are good

ioreg_gpu.zip

[Stezza88]

My forked weg 1.7.0 and lilu 1.7.2

sources

 

WhateverGreen.zip Lilu.zip

Edited May 11 by Stezza88

[jalavoui]

u're uploading to github?

 

[Stezza88]

I'm with amd passing sources with an usb pen

yes ia and GitHub upload are working... only a safari extension doesn't work

 

it tells closure unanexpected of safarilinkextension... and cannot reload page

Edited May 11 by Stezza88

[jalavoui]

u gonna move code to WhateverGreen or clean ngreen? i see new code on both

 

i dont get this log? what is this?

2026-05-11 20:31:33.589396+0200  localhost kernel[0]: (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 4899 ][getPlatformID       ]   Undefined platform ID - update OS driver
this looks like ai hack

Edited May 11 by jalavoui

[Stezza88]

Nblue in First Page Is my stub to boot in rpl with empty iopciprimarymatches with iondrv..

 

2 minutes ago, jalavoui said:

u gonna move to code to WhateverGreen or clean ngreen? i see new code on both

 

I use both togheter ... Order in kernel add : First lilu, second ngreen, third weg

 

With coexistance ARG they work perfectly

I wanna push both

Now a pause... It's been 1-2 hard months pasts

Edited May 11 by Stezza88