jalavoui Posted Saturday at 02:14 PM Share Posted Saturday at 02:14 PM (edited) gonna leave the bins untouched on other thread till we find something better i'm loking at nvram and cameliia (china) registers added saved-config var to nblue sources + savednvram patch for kernel call masta can you test it? what happens if you disable the applebacklight ?. the displays gets full brightness? Edited Saturday at 04:33 PM by jalavoui Link to comment Share on other sites More sharing options...
Mastachief Posted Saturday at 03:40 PM Share Posted Saturday at 03:40 PM This boot is using the updated nblue source, just disabled net and compiled, didnt edit connectors as it gives a hang.Boots the same as before at half brightness.The pnlf is disabled, you can check my config.plist in the github, however, it's still half brightness. hackintool boot.logHackintool system.log Link to comment Share on other sites More sharing options...
jkbuha Posted Saturday at 04:13 PM Share Posted Saturday at 04:13 PM 4 hours ago, jalavoui said: jkbuha can you link us your github ? https://github.com/jkbuha/XPS-9730-RaptorLake-OpenCore Link to comment Share on other sites More sharing options...
jkbuha Posted Saturday at 05:25 PM Share Posted Saturday at 05:25 PM (edited) 5 hours ago, jalavoui said: Xe IGPU (0x46a6) is kinda same family as asus laptop (check his thread) from is logs i think is doable - load adl in tgl framebuffer. the connector patch you mentioned is so easy todo using nblue (conn zero). but i think other issues will pop up don't think at 0x9a49 as a limitation. it is the way i foud out to link tgl settings with tgl fram kext graphics kext. waht really makes the driver works are the patches idk what you guys need todo it but we here to help Thanks, and it's much appreciated. Apologies in advance if anything I say or do is noob-level, as I'm out of my comfort zone here. I have finally successfully managed to build the first working kext for NootedBlue that loads, at least I think it does, but framebuffer still shows 8MB (so I guess framebuffer not correct). But it doesn't KP anymore with Unsupported ICL Sku, so something is done right atm. Things I've only changed so far: static uint8_t builtin[] = {0x00}; static uint8_t builtin2[] = {0x00, 0x00, 0x05, 0xFF}; // this ICL framebuffer worked for me with WG, am assuming I should test with this? static uint8_t builtin3[] = {0xA6, 0x46, 0x00, 0x00}; // my native device-id, should I still keep this enabled? Other points worth of note: AAPL,ig-platform-id set to 000005FF. Connectors in DeviceProperties set just as my github (9520) Julian's XPS 9520 Macbook Air - NootedKextLoaded.ioreg.zip Edited Saturday at 05:36 PM by jkbuha Link to comment Share on other sites More sharing options...
jalavoui Posted Saturday at 05:38 PM Share Posted Saturday at 05:38 PM (edited) in theory having the device id match ig-platform helps loading the acelerator due to internal checkings. hope you also follow asus work he is almost done loading tgl. to load the system icl frame you need to swap card-ids in nblue info.plist. it is defaulted to TGLle ICLle is debug version from DTK and is installed to /L/E Gen7 are the acelerators. if you add a card-id to any of this properties and the kext fails to load you might get a boot hang from what you're saying i would go for TGLle as icl is bit old for our cards and btw you dont need to inject anything (in theory) with OC your ssdtd are so good i'm review mines. noticed you dont have this. think it is needed for intel graph kexts + the classic Edited Saturday at 06:28 PM by jalavoui 1 Link to comment Share on other sites More sharing options...
Stezza88 Posted Saturday at 10:05 PM Share Posted Saturday at 10:05 PM On 5/14/2024 at 3:15 PM, Mastachief said: On Dortiana's Github guide page, look for the Patching Bus IDs page, however the patch shown is not with IceLake, I am going to use the icelake framebuffer below as an example though. ID: 8A510002, STOLEN: 64 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000E304 TOTAL STOLEN: 193 MB?, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 193 MB, MAX OVERALL: 194 MB (203960320 bytes) Model name: Intel Iris Plus Graphics Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 0, type: 0x00000002, flags: 0x00000018 - ConnectorLVDS [2] busId: 0x09, pipe: 1, type: 0x00000400, flags: 0x000002C1 - ConnectorDP [3] busId: 0x0A, pipe: 1, type: 0x00000400, flags: 0x000002C1 - ConnectorDP 00000000 00000000 00000000 00000000 02000000 18000000 02000000 09000000 01000000 01000000 00040000 C1020000 03000000 0A000000 01000000 01000000 00040000 C1020000 Les analyze the first line for use with the alldata method; [0] busId: 0x00, pipe: 0, type: 0x00000002, flags: 0x00000018 - ConnectorLVDS 00000000 00000000 00000000 00000000 02000000 18000000 I have a few notes below, if you put the original values into a table to break down what they are saying using "00000000 00000000 00000000 00000000 02000000 18000000" Bit Name Value Bit 1 Port 0 Bit 2 Bus ID[SM1] 0 Bit 3-4 Pipe Number 0000 Bit 5-8 Connector Type 02000000 Bit 9-12 Flags 18000000 [SM1] BusID is a unique value and cannot be used by multiple entries This is the portion that will be used in setting up the framebuffer for a specific connector, see below for the ioreg that is currently shown when i boot currently using the whenvergreen attached. For the GPU the "display0' is being seen under AppleIntelFramebuffer@1 instead of AppleIntelFramebuffer@0, when jala did the changes, he was able to get this change done using nblue, but there were issues. The method was to setup the framebuffer-con0-XXXX settings that are needed using the alldata method Do note that there are three (3) framebuffers however it is numbered 0, 1, 2, 3 , example AppleIntelFramebuffer@0, AppleIntelFramebuffer@1, AppleIntelFramebuffer@2. You have to then disable framebuffer-con0-alldata and framebuffer-con2-alldata and framebuffer-con3-alldata, by zeroing the bus id on those specific indexes, example for AppleIntelFramebuffer@2 below; 03000000 00000000 01000000 01000000 00040000 C1020000 You should also then do the same for framebuffer-con0-alldata and framebuffer-con3-alldata you will then have the framebuffers in your device properties section for the IGPU, the index explanation Port: Port is Index number, its usually 0 only for the internal GPU Bus ID: Bus ID is the bus that the device is attached to Pipe Number: Dont know, read the info that comes up when you hover over the value while using hackintool Connector Type: a value that is generated based on the ticked options in hackintool under the patch tab and the connectors sub menu, a list taken from Dortiana is below. <02 00 00 00> LVDS and eDP - Laptop displays <10 00 00 00> VGA - Unsupported in 10.8 and newer <00 04 00 00> DisplayPort - USB-C display-out are DP internally <01 00 00 00> DUMMY - Used when there is no physical port <00 08 00 00> HDMI <80 00 00 00> S-Video <04 00 00 00> DVI (Dual Link) <00 02 00 00> DVI (Single Link) This Is a good piece of thread for me.. 1 Link to comment Share on other sites More sharing options...
Mastachief Posted Saturday at 11:09 PM Share Posted Saturday at 11:09 PM I did another post after that with a device properties config that had all the connectors set where I then had the display connected under framebuffer 0 using whatevergreen, it had the entire set of values to be used using the all data method.However when I tried to replicate this connector values to the first 3 connectors in the latest iteration of nooted blue, it gave a hang on boot, I should investigate just be sure. Link to comment Share on other sites More sharing options...
jalavoui Posted Saturday at 11:15 PM Share Posted Saturday at 11:15 PM (edited) indeed masta let me check for the properties in tgl driver. i remenber saw then so nblue as 3 connectors that you can overwrite using opencore. most important is con zero - make the lcd display work i don't remenber this flags but wg as docs about them so AAPL00,override will alow edid injection - not sure which1 hope you can find something about this all this flags are read by the tgl driver. this is nice cause we can inject panel power cycle delay from linux values and maybe help on backlight support using camellia and banksia code messing with this port really brings lots of hangs/broken display. i've tested some changes and it only gets worst Edited Sunday at 02:59 AM by jalavoui Link to comment Share on other sites More sharing options...
jalavoui Posted Saturday at 11:36 PM Share Posted Saturday at 11:36 PM (edited) so this code as linux ref and is here ty linux for clarifying added some of the linux workarounds to nblue srcs - will be needed for aceleration Edited Sunday at 04:34 PM by jalavoui Link to comment Share on other sites More sharing options...
jalavoui Posted Sunday at 08:50 PM Share Posted Sunday at 08:50 PM (edited) from here? /* WaEnableChickenDCPR:skl,bxt,kbl,glk,cfl */ intel_uncore_rmw(&i915->uncore, GEN8_CHICKEN_DCPR_1, 0, MASK_WAKEMEM); this register "fix" also used in... void AppleIntelPowerWell::enableDisplayEngine(void) but they say code from 1969 Edited Sunday at 09:19 PM by jalavoui Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 07:09 PM Share Posted Monday at 07:09 PM (edited) i almost forgot that we are now in tgk so the question which backlight do we have ?? Edited Monday at 07:18 PM by jalavoui Link to comment Share on other sites More sharing options...
Mastachief Posted Monday at 11:35 PM Share Posted Monday at 11:35 PM (edited) Well, something is setting the brightness to mid brightness on boot when using either Production/Debug. Look in my github, it had the registers i wrote to in my tests. ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8254 (0x000c8254): 0x00017700 (freq 1, cycle 30464) ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8254 (0x000c8254): 0x00017700 (freq 1, cycle 30464) ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00047700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00037700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00027700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00012700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg write 0xc8254 0x00017700 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8255 0x00012700 (0x000c8255): 0xfd000177 (0x00012700): 0x00000000 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8253 0x00012700 (0x000c8253): 0x0000fd80 (0x00012700): 0x00000000 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8256 0x00012700 (0x000c8256): 0x00fd0001 (0x00012700): 0x00000000 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8257 0x00012700 (0x000c8257): 0x0000fd00 (0x00012700): 0x00000000 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8258 0x00012700 (0x000c8258): 0x0000b6d3 (0x00012700): 0x00000000 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8253 0x00012700 (0x000c8253): 0x0000fd80 (0x00012700): 0x00000000 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8254 (0x000c8254): 0x00017700 (freq 1, cycle 30464) ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8255 (0x000c8255): 0xfd000177 ubuntu@ubuntu:/etc/X11/xorg.conf.d$ sudo intel_reg read 0xc8255 (0x000c8255): 0xfd000177 TIme to whip out the old Ubuntu USB, got to edit my grub to grab debug, which Glavor GNU/Linux and Kernel are you using to pull your info Jala? Wanna be as close as possible in producing results. or did you just use the lastest driver with the current Kernel? like this one ---> https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2024-2/rebuild-and-install-i915-module-ubuntu.html Edited 7 hours ago by Mastachief Link to comment Share on other sites More sharing options...
jalavoui Posted Monday at 11:50 PM Share Posted Monday at 11:50 PM (edited) masta any linux is fine. just make sure you update the linux kernel maye the inital tgl code works partial for your display one of this calls ? you can try hack this condition for testing. there's a banksia conditon also available at AppleIntelBaseController::start(AppleIntelBaseController *this,IOService *param_1) you can also try to inject the value maybe at new workarounds call function from nblue this is disabled by default in nblue. i enabled and got the backlight slider working. the range needs a fix Edited 11 hours ago by jalavoui Link to comment Share on other sites More sharing options...
Mastachief Posted 7 hours ago Share Posted 7 hours ago (edited) Putting some info here in case i lose it. macOS has its own graphics drivers, which often abstract direct hardware register access. The macOS drivers (like AppleIntelFramebuffer or AppleIntelGraphics) typically interact with the GPU through Apple’s APIs and might not expose registers in the same way that the i915 driver does on Linux. Because of this, we might not have direct access to these registers in macOS as you would with Linux’s intel_reg tool. the memory maps are resovled to MMIO region.... i915_boot_log.zip i915_dmesg_log.txt all_registers.txt 0000:00:02.0.zip ACPI.zip xrandr verbose info.txt Edited 6 hours ago by Mastachief 2 Link to comment Share on other sites More sharing options...
Recommended Posts