McSonite 0 Posted November 29, 2020 Posted November 29, 2020 Hi All, This is my first OpenCore project. I'm running OC 0.6.3 and Catalina 10.15.7 in HP EliteOne 800 G1 All-in-One PC. This is an All-in-One PC (you might have decoded this from the PCs name ) and thus has an LVDS display. There is also one DP connector at the back of the machine. The problem is that I cannot get the iGPU running with 3D acceleration on the LVDS display. I have tried every gimmick in the Patching Whatevergreen guide. Best results I get when running with ig-platform-id 0300220D, framebuffer-stolenmem 00003000 and framebuffer-fbmem 00009001. But there is a catch here: Booting with above properties the LVDS goes black after the DSMOS has arrived. I had a feeling that graphics are actually displayed through the DP connecter. So, I went and grabbed an external display and connected it to the DP connector - and voila I have 3D acceleration. 'About This Mac' also shows that there is 1536MB of memory for the Intel HD Graphics 4600. I have spent vast amount of hours (60+) to get the 3D acceleration working on LVDS with no luck. Notes: I have gone through all the Haswell specific ig-platform-ids for both desktop and laptop. Most of these work but only without 3D acceleration and 7MB of memory for the graphics. If DP is connected during the boot process the machine hangs with error: Adding AGDP mode validate property. If I let the machine boot without DP connected so that the LVDS gets black and connect the DP after that I get the picture on the DP connected screen. When I started the project I had AppleALC kext installed and with most of the ig-platform-ids the machine kernel paniced during the boot process. I replaced the AppleALC with VoodooHDA and after that the kernel panics were gone - and I also got sounds working. I would appreciate a lot if someone could give me advice on how to get the 3D accelerated picture on the LVDS display. Regards McSonite Quote Share this post Link to post Share on other sites
Hervé 2,039 Posted November 29, 2020 Posted November 29, 2020 Please post zipped copies of config + IOReg (from IORegistryExplorer). Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 (edited) Here is the config file and snapshots from IOreg excerpt. I was unable to mask out the SN and other stuff from the IOReg output therefore I have attached only screenshots concerning the IGPU2. Please ask for more screenshots if needed. config.plist.zip Edited November 30, 2020 by McSonite zipped config.plist Quote Share this post Link to post Share on other sites
Hervé 2,039 Posted November 30, 2020 Posted November 30, 2020 Sorry but such screenshots are just useless. If you have concerns about showing your serial numbers, make a backup of your current config and change your serial numbers before posting the required IOReg. You know, good common sense... There's a typo in the properties injection you've defined in your config file: framebuffer-fbmm instead of framebuffer-fbmem So that injection is clearly without effect; not that this is the reason for your built-in screen issue, but... Please note that framebuffer memory size and stolen memory size don't usually require patching on HD4600 graphics so I'm not sure there's anything to gain with your properties injection in that respect (especially as you inject the same StolenMem value as the default one!). The only thing that usually requires patching is the cursor memory size if graphics get glitchy (increase to 9MB). If you look into (Catalina's) Azul framebuffer, you'll see: 1) desktop layout 0x0D220003 0300220D 00030303 00000002 00003001 00000000 00000060 99140000 99140000 00000000 00000000 01050900 00040000 87000000 02040A00 00040000 87000000 03060800 00040000 11000000 FF000000 01000000 40000000 020C0000 01010000 04000000 00000000 0E000000 00000000 where: 0300220D -> FB id 00030303 -> Mobile:00 PipeCount:03 PortCount:03 MemCount:03 00000002 -> StolenMem:32MB 00003001 -> FBMem:19MB 00000000 -> CursorMem:0MB 00000060 -> VRAM:1536MB 99140000 -> Freq:5273Hz 99140000 -> MaxFreq:5273Hz 00000000 00000000 01050900 00040000 87000000 -> con0:DP 02040A00 00040000 87000000 -> con1:DP 03060800 00040000 11000000 -> con2:DP FF000000 01000000 40000000 020C0000 01010000 04000000 00000000 0E000000 00000000 2) mobile layout 0x0A260006 0600260A 01030303 00000002 00003001 00006000 00000060 D90A0000 D90A0000 00000000 00000000 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 where: 0600260A -> FB id 01030303 -> Mobile:01 PipeCount:03 PortCount:03 MemCount:03 00000002 -> StolenMem:32MB 00003001 -> FBMem:19MB 00006000 -> CursorMem:6MB 00000060 -> VRAM:1536MB D90A0000 -> Freq:2777Hz D90A0000 -> MaxFreq:2777Hz 00000000 00000000 00000800 02000000 30000000 -> con0:LVDS/eDP 01050900 00040000 87000000 -> con1:DP 02040900 00040000 87000000 -> con2:DP FF000000 01000000 40000000 0F000000 01010000 04000000 00000000 0E000000 00000000 This is further detailed in WEG manual or Hackintool which decode the above Azul framebuffers as follows: ID: 0D220003, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x00000402 TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000087 - ConnectorDP [3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x00000011 - ConnectorDP 01050900 00040000 87000000 02040A00 00040000 87000000 03060800 00040000 11000000 and ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 So, you'll see that: Azul desktop framebuffer 0x0D220003 defines 3 x DP output ports by default. No LVDS port. Azul mobile framebuffer 0x0A260006 defines 1 x LVDS output and 2 x DP ports by default. 2 x questions: are you sure your internal display is actually of LVDS type? what CPU model is your AIO computer fitted with? You could try the mobile framebuffer with the associated SMBIOS (eg: MBP11,1) for instance but you really should confirm built-in screen type 1st and foremost. If it really is LVDS, you could try and inject that type (02000000) to the 1st connector of the framebuffer, knowing that you'd probably have to experiment with Index and BusId too. But know that iMac 14,1/14,4 have their built-in display attached to ports of DP connector types... Another thing to try is boot arg agdpmod=pikera. This effectively bypasses AppleGraphicsDevicePolicy kext which can restrict display output capabilities of given Mac models and therefore Hackintoshes that use their SMBIOS profiles. Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 Thank you for your quick reply. I actually am not concerned about the SN shown. I just read this from the New Users' lounge that you should take them away. Typo in fbmem was my bad. I just tried to replicate the config.plist that I had during the time of the IOReg capture. I'm not 100% sure about the display type but I suspect that it is LVDS because there is a BIOS setting for this i.e. setting the LVDS type: auto - Samsung - LG Processor is: Intel Core i5-4570S I have also tried this laptop buffer ID 0A260006 but machine posts with it only if I add -igfxvesa to the boot args. I have also tried changing the connector type with following parameters (running the mentioned recommended desktop buffer) framebuffer-con1-enable | data | 01000000 framebuffer-con1-type | data | 02000000 I will go on testing the SMBIOS 11,1 and also agdp=pikera ioreg_snap.zip Quote Share this post Link to post Share on other sites
Hervé 2,039 Posted November 30, 2020 Posted November 30, 2020 Please note that, as shown in your IOReg, port #0 is actually on con2 in framebuffer 0x0D220003. You may also notice that con2 registers as your boot display. This is actually consistent to what an iMac14,1 would show for instance: built-in display attached to FB@2. con0 is port #5 and con1 is port #7 (this is what your DP external screen attaches to). So, to me, con2 is the connector you need to work on... Given that your AIO has a quad-core i5-4570S CPU, I would also suggest you change your SMBIOS to iMac14,1 (quad-core i5-4570R + Iris Pro 5200 graphics) rather than iMac14,4 (dual-core i5-4260U + HD 5000 graphics). Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 I have now tested with SMBIOS MacBookPro11,1 and with and without agdp=pikera - no luck. The only way to get the machine post is with the fb 0x0D220003 and it starts with black screen on the LVDS display. I changed the SMBIOS back to iMac14,4 I think I just have to give up 'cause I don't grasp the patching system and or how it correlates with the SMBIOS. Quote Share this post Link to post Share on other sites
Hervé 2,039 Posted November 30, 2020 Posted November 30, 2020 Well, it's really not that difficult: 1) Inject the following properties for your iGPU located at PciRoot(0x0/Pci(0x2,0x0) AAPL,ig-platform-id 0300220D DATA framebuffer-patch-enable 01000000 DATA framebuffer-con2-enable 01000000 DATA framebuffer-con2-type 02000000 DATA 2) add boot arg agdpmod=pikera to your existing list in NVRAM section 3) for optimum CPU power management, whilst retaining support for HD4600 graphics, change your SMBIOS to iMac14,1. You may use Clover Configurator or GenSMBIOS tool to generate the required data, then add it to your OC config as documented in Dortania's OpenCore guide. Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 Ok. Will do. Is the con2-type data 00000002 because this could have been where I have gone wrong. I have user 02000000 I'll report after the test. Quote Share this post Link to post Share on other sites
Hervé 2,039 Posted November 30, 2020 Posted November 30, 2020 Was still editing my post when you added your reply... LVDS connector-type is 02000000. Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 Unfortunately with these settings it starts with black screen. (Currently no external display connected to DP). Quote Share this post Link to post Share on other sites
Hervé 2,039 Posted November 30, 2020 Posted November 30, 2020 Can you try and add the boot arg -igfxvesa to boot without graphics support. It's just to check if you'd get something on screen, in which case, take and IOReg and post it. Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 With -igfxvesa it works. This is how I got it installed in the first place. Note (if this has anything do with anything): The earlier IOReg that I posted was taken when the external display was connected to the DP port. Quote Share this post Link to post Share on other sites
McSonite 0 Posted November 30, 2020 Posted November 30, 2020 (edited) .. and the IOreg file ioreg_igfxvesa.zip Edited November 30, 2020 by McSonite Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 1, 2020 Posted December 1, 2020 Any ideas what to start doing with the con2 ? Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 2, 2020 Posted December 2, 2020 Ok. So, I installed Windows (yeah, I know, sorry about Win. None of the Linux distros I tried weren't running the Intel HD correctly i.e. screen res only 800x600 and they started w/ nomodeset or graphics safe mode only) in order to get more info on the Built-in-display. Intel HD Graphics Control Panel tells me that the connector type is actually Embedded DisplayPort. Now the question goes: What connector type should I choose for con2 if I'm using framebuffer 0D220003? Currently the deafult is DP and with that the screen is black. Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 2, 2020 Posted December 2, 2020 Is there something to debug this with? I'm not familiar with OC - Clover differences. In Clover there seems to be kexts for correcting the black screen issue and OC just tells to remove all the kexts and go with the WEG kext and patch it. Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 3, 2020 Posted December 3, 2020 (edited) Found out something while tweaking the MacOS via remote connection. VNC works while the screen is black. When running IORegExplorer it seems that FB2 connector type changes to 00080000 (HDMI). I suspect that the VoodooHDA or audio mapping to HDMI is the culprit in someway. I added -igfxnohdmi and then the connector type was 00040000. Edited December 3, 2020 by McSonite Corrected the connector types Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 3, 2020 Posted December 3, 2020 (edited) I'm following Dortania's guide to patch BusIDs but whatever I do I get HDMI defined for each FB as a connector type. BusID for indices 1 and 2 is set to 00 because I want to disable these. Can someone shed some light and tell me why? ioreg_allhdmi.zip config.plist Edited December 3, 2020 by McSonite Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 3, 2020 Posted December 3, 2020 11 minutes ago, McSonite said: I'm following Dortania's guide to patch BusIDs but whatever I do I get HDMI defined for each FB as a connector type. BusID for indices 1 and 2 is set to 00 because I want to disable these. Can someone shed some light and tell me why? ioreg_allhdmi.zip config.plist Let me do it myself. I was missing framebuffer-patch-enable. I'm losing my mind trying to understand this patching. Index, BusID, Pipe, conX, port, FB how it is in SMBIOS. Just cannot find a guide that matches these terms. I understand that this sounds like rantings of a blubbering idiot but... port #0 is actually on con2 con0 is port #5 con1 is port #7 How to for example decipher that? It needs not to be explained here but I would like someone to refer to a link where I can read this. Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 4, 2020 Posted December 4, 2020 Simple question: When the connector is eDP and I'm patching a framebuffer: Which connector type am I supposed to use LVDS 02000000 or Display Port 00040000? I have followed https://dortania.github.io/OpenCore-Post-Install/gpu-patching/intel-patching/busid.html#mapping-the-video-ports, used FB 0x0D220003 and gone though all the possible iterations with the BusIDs always disabling two of them and I have been using connector type 02000000 i.e. 01010900 02000000 87000000 02000A00 00040000 87000000 03000800 00040000 11000000 01020900 02000000 87000000 02000A00 00040000 87000000 03000800 00040000 11000000 01030900 02000000 87000000 02000A00 00040000 87000000 03000800 00040000 11000000 etc. and 01000900 00040000 87000000 02010A00 02000000 87000000 03000800 00040000 11000000 01000900 00040000 87000000 02020A00 02000000 87000000 03000800 00040000 11000000 01000900 00040000 87000000 02030A00 02000000 87000000 03000800 00040000 11000000 etc. and same for the index 3. And also I have tested all iterations with flags being 0x8 (https://github.com/acidanthera/WhateverGreen/blob/master/Manual/IntelFramebuffer.bt) /* Normally set for LVDS displays (i.e. built-in displays) */ uint8_t CNConnectorAlwaysConnected :1; /* 0x8 */ i.e. 01010800 02000000 87000000 02000A00 00040000 87000000 03000800 00040000 11000000 01020800 02000000 87000000 02000A00 00040000 87000000 03000800 00040000 11000000 01030800 02000000 87000000 02000A00 00040000 87000000 03000800 00040000 11000000 etc. and same for indices 2 and 3 I still always get black screen on the built-in-display (SMBIOS is currently set to iMac14,1) Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 5, 2020 Posted December 5, 2020 Can someone please help me out? When it works I'm able to backtrack what was done and maybe start understanding something about the patching process. Quote Share this post Link to post Share on other sites
McSonite 0 Posted December 6, 2020 Posted December 6, 2020 (edited) No, no, no on no... 20+ hours used. No luck. I have now tried to inject EDID of the built-in display. How to tell which one of the following to use? AAPL00,override-no-connect AAPL01,override-no-connect AAPL02,override-no-connect Edited December 6, 2020 by McSonite Forget about the config.plist. It is full of errors. Quote Share this post Link to post Share on other sites
