Search the Community

Hi, I have tried to connect my HDMI monitor to my Laptop and here are the problems I faced: 1- The HDMI monitor is connected but completely black. 2- The HDMI monitor audio is some how working but as you can see in the included screenshot I can't control the volume directly from the system. 3- The HDMI monitor appears black ONLY when I uncheck "Mirror Displays" or in other words the screen mirroring works. 4- My graphics card is read as 2048Mb and I couldn't change that, because I know it can cause problems. My specs: Dell 5570 macOS Catalina.10.15.4 i5-8250U AMD 530 / intel U620 8GBs ram 240GBs SSD 1Tb HDD HDMI monitor specs: normal Samsung 32" TV debug_31225.zip

Hey thanks for the guide! Unfortunately it didn't fix my issue, I tried the method mentioned in the above thread and I suspect that with my HDMI display plugged in (because that's the only way I can use my hackintosh) it was generating the external display's edid. So I installed windows on my computer using the Nvidia control panel and selected my internal monitor's edid. I tried injecting that edid(internal display) using clover but still only the external display is working with graphics acceleration. P.S. I also tried booting by disabling the Nvidia from clover and followed the guide above but Darwin Dumper then wouldn't give me those three files a.k.a my EDID folder debug_28456.zipwas empty. Please it will really appreciated if you could help me through this issue. I'm adding my problem reporting files.

Hello friends, Many of you have noticed that after upgrade to high sierra whenever you machine sleeps, be it a display sleep or a system sleep, the screen turns out fully white with garbled lines, or it might turn black with just the cursor moving. If you try and press few keys you will find out that the machine works but the display doesn't. If you want to know a little background info, read on, else skip to fix. On my ASUS R541UJ this bugged me a lot. I tried hell lot of things like, re patching DSDT, trying with all 15 ig-platform-id (for Kabylake), still, the issue persisted. I also have an ASUS A555LA (which I am trying to make a perfect MacBook Air). So, in my process of making my A555LA a perfect MacBook I added a ALS (ambient light sensor device) and then, changed vendor-id along with product-id of the laptop's display to that of Apple's display i.e. PID: 0x9cf2 VID: 0x610 for MacBook Air's display.. Whatever I do on my A555LA, I replicate the same on my 2 other ASUS laptops. So, I did the same on my R541UJ (the one affected by this annoying bug) And to my surprise, that issue was fixed! Then, I disabled the ALS device in my custom SSDT (I generally make a dynamic configurable SSDT that works for all my machines, See here) and that issue didn't come back. So, I finally came to the conclusion that it was due to incorrect vendor-id and product-id of my display in IODisplayEDID or EDID. Enough talking, let's see how you can fix this in a few simple steps. How to fix: In order to fix this, as you might already know from above, we need to change our display's product and vendor id to that of Apple's display. There are 3 ways for this, Injecting custom EDID using clover, Using a display override, Using a custom override kext (DispalyMergeNub). I love CLOVER so will be covering that part of the fix in this guide. Also, injecting EDID with clover is preferred as it will also work when booting recovery partition. (Not the same with Display Overrides and DisplayMergeNub) Update your CLOVER to latest version (nothing to do with this fix but is a good idea to have you boot loader up to date) Download Darwin Dumper from here Download FixEDID app from here Download my script attached to this post. Open Darwin dumper and uncheck everything except EDID. Then, select run from the left pane. It will dump your EDID and then it will open a folder where it dumped the files. In the folder you will find an EDID folder. Upon opening it you will see 3 files namely, EDID.bin, EDID.hex, EDID.txt (All three files are your EDID dump except in different formats). We need the one in BIN format for FixEDID.app Copy EDID.bin from DarwinDump*/EDID to your Desktop (Dump* is the darwinDumper output folder) Open FixEDID.app and select open EDID binary file. Choose the EDID.bin file you copied to desktop. If you look below "Open EDID binary file" button, you will see a drop down menu saying "Apple iMac Display 16:10" Select it and choose "Apple MacBook Air Display 16:9" (Note: You may try experimenting with different models, I personally use "Apple MacBook Air Display 16:9" on my A555LA and "Apple MacBook Pro Display 16:10" on my R541UJ) Make sure display class is set to "AppleBacklightDisplay" for we are overriding our internal LVDS display. (AppleDisplay is used for external displays like that on HDMI or DP) Click on Make button (Note: You won't see any sort of confirmation but the app has done it's work) Close FixEDID and come back to your desktop. You will see a host of new files there. (3 files to be precise) For this guide, you just need DisplayVendorID-xxx folder. Open it any then you will find a file named "DisplayProductID-xxxx" Copy this file to the Desktop. Now we need to extract EDID that is in base64 format and then convert it to HEX format as required by CLOVER. Worry not, I got you covered. Now is the time to run my script. Assuming my downloaded script is in Downloads folder, open terminal and type: # Change working directory cd ~/Downloads # Make script executable chmod a+x get_edid.sh # Run and get EDID to inject ./get_edid.sh ~/Desktop/DisplayProductID* ` This script wil give you EDID you need to inject using CLOVER, like: Copy that EDID and paste it in your config.plist under Graphics > EDID > Custom (You can use clover configurator as that will save you from manual PLIST editing which is not recommended for novice users) Also, set Boolean Inject to True (YES) under config.plist > Graphics > EDID. See below screenshots for reference: Any Plist Editor(Xcode): Clover Configurator: Reboot and Voilà! You won't face that dreaded issue ever again until you remove custom EDID. LOL. You can verify if the EDID is being injected by opening terminal and typing: ioreg -l | grep "IODisplayEDID" ` The output should match the output of get_edid.sh Problem Reporting: See How to generate proper problem reporting files Note: This issue mostly seems to effect machines running High Sierra on Kabylake hardware (maybe Skylake too?). I have personally tested this on Sierra (with and without skylake spoofing) turns out that Sierra is not affected by this. Note: Upon booting up with custom EDID in place you will see that your colors are not such bright and crisp. YMMV. (Coz our's isn't a Apple branded display ). To fix that, open system preferences > Display. Select "Color" tab and choose "Apple RGB Display" Hope this helped someone! Regards get_edid.zip

Ok, I've been looking a bit at this situation, and I've found the following, using the model_data in SVN revision 564: 1.) The DSDT.aml for the D620-nvidia and the D820-nvidia are identical (used DSDTSE to decompile to .dsl): $ diff -u *.dsl --- dsdt-d620-nv.dsl 2013-04-27 11:44:28.000000000 -0400 +++ dsdt-d820-nv.dsl 2013-04-27 11:44:42.000000000 -0400 @@ -2,7 +2,7 @@ * Intel ACPI Component Architecture * AML Disassembler version 20091214 * - * Disassembly of ./dsdt.aml, Sat Apr 27 11:42:53 2013 + * Disassembly of ./dsdt.aml, Sat Apr 27 11:43:09 2013 * * * Original Table Header: $ 2.) The smbios.plist is different, and not just a little different: $ diff -u Dell_Latitude_D620-nvidia/common/smbios.plist Dell_Latitude_D820-nvidia/common/smbios.plist --- Dell_Latitude_D620-nvidia/common/smbios.plist 2013-03-30 13:38:10.000000000 -0400 +++ Dell_Latitude_D820-nvidia/common/smbios.plist 2013-03-30 13:37:43.000000000 -0400 @@ -5,15 +5,15 @@ <key>SMUUID</key> <string></string> <key>SMbiosdate</key> - <string>2/29/2008</string> + <string>10/12/06</string> <key>SMbiosvendor</key> - <string>Apple Inc.</string> + <string>Apple Computer, Inc.</string> <key>SMbiosversion</key> - <string>MB21.00A5.B07</string> + <string>MB11.88Z.0061.B03.0610121324</string> <key>SMboardmanufacturer</key> <string>Apple Computer, Inc.</string> <key>SMboardproduct</key> - <string>Mac-F42C88C8</string> + <string>Mac-F4208CC8</string> <key>SMfamily</key> <string>MacBook</string> <key>SMmanufacturer</key> @@ -21,10 +21,10 @@ <key>SMmemmanufacturer</key> <string>Apple Computer Inc.</string> <key>SMproductname</key> - <string>MacBook2,1</string> + <string>MacBook1,1</string> <key>SMserial</key> <string>5W4ZPC123</string> <key>SMsystemversion</key> - <string>1.1</string> + <string>1.0</string> </dict> </plist> $ Huh?!? The D620 with nVidia is a MacBook 2,1 but the D820 with the same nVidia is a MacBook 1,1? That can't be right. 3.) The org.chameleon.Boot.plist differs: $ diff -u Dell_Latitude_D620-nvidia/common/org.chameleon.Boot.plist Dell_Latitude_D820-nvidia/common/org.chameleon.Boot.plist --- Dell_Latitude_D620-nvidia/common/org.chameleon.Boot.plist 2013-03-30 13:38:10.000000000 -0400 +++ Dell_Latitude_D820-nvidia/common/org.chameleon.Boot.plist 2013-03-30 13:37:43.000000000 -0400 @@ -2,12 +2,8 @@ <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> - <key>EHCIacquire</key> - <string>Yes</string> <key>EthernetBuiltIn</key> <string>Yes</string> - <key>ForceHPET</key> - <string>Yes</string> <key>GenerateCStates</key> <string>Yes</string> <key>GeneratePStates</key> @@ -26,15 +22,9 @@ <string>Default</string> <key>Timeout</key> <string>2</string> - <key>UHCIreset</key> - <string>Yes</string> - <key>USBBusFix</key> - <string>Yes</string> <key>arch</key> <string>i386</string> <key>UseKernelCache</key> <string>Yes</string> - <key>device-properties</key> - <string>5c0400000100000001000000500400001700000002010c00d041030a000000000101060000010101060000007fff04000e0000004e00560050004d00000020000000010000000000000000000000000000000000000000000000000000001c000000400030002c00660062006f006600660073006500740000000800000000000200360000004100410050004c002c006100750078002d0070006f007700650072002d0063006f006e006e0065006300740065006400000008000000010000001c0000006400650076006900630065005f00740079007000650000000f0000004e5644412c506172656e74240000004100410050004c00300030002c0069006e0076006500720074006500720000000800000000000000220000004100410050004c002c0067007200610079002d00700061006700650000000800000001000000320000004100410050004c002c006200610063006b006c0069006700680074002d0063006f006e00740072006f006c0000000800000001000000420000004100410050004c00300030002c0062006c00610063006b00730063007200650065006e002d0070007200650066006500720065006e0063006500730000000800000000000008100000006d006f00640065006c0000001e0000006e56696469612051756164726f204e5653203131304d20454649160000006200750069006c0074002d0069006e000000050000000022000000400030002c006400650076006900630065005f00740079007000650000000b000000646973706c61791c000000400031002c006200750069006c0074002d0069006e0000000400000022000000400031002c006400650076006900630065005f00740079007000650000000b000000646973706c617920000000400031002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d616314000000400030002c006e0061006d0065000000120000004e5644412c446973706c61792d411c000000400030002c006200750069006c0074002d0069006e0000000400000014000000400030002c004e0056004d00540000005c0000000a037f204c2d1c0278051a044807d0056006000041041d0421040000f0c1410700000100000000ff00000000000000000000000000000000000000000000000000000000ffff00000000000000000000010000000000000014000000400031002c006e0061006d0065000000120000004e5644412c446973706c61792d421200000049004f004e0061006d00650000000b000000646973706c617920000000400030002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d616324000000400031002c00630061006e002d0068006f0074002d0070006c0075006700000004000000100000004e00560043004100500000001800000004000100000003000c0000000000000a000000002a00000049004f0050004d004900730050006f007700650072004d0061006e00610067006500640000000500000001</string> </dict> </plist> $ That's also not a small difference, with the D620's containing a lot more (and this is the exact .plists I'm booting my D820/M65 with right now!). Hmm, what about the Intel GMA D820..... Same thing, the D820 gets a MacBook1,1 but the D620 is MacBook2,1; but I don't have a D820-Intel to test on, so it might very well work that way on the D820-intel). In a similar light, my Inspiron 9400 (GMA950, 1920x1200 screen) works as a D620-intel-high (MB2,1) but won't work with the smbios.plist provided in the Inspiron_9400 EDP (set up as a MBP3,1). My D820/P-M65 is happy with the D620 EDP (as a MacBook2,1) but it is not happy with the D820 EDP (as a MacBook 1,1). For that matter, my D820/M65 is happy without a DSDT.aml or smbios.plist at all, using the leppy700m BootCD (happier, in ways, since the VGA and DVI ports on the D/Dock work with the leppy700m BootCD but don't with the D620 EDP). But that is of course a substantially older Chameleon..... Anyway, there's a few data points....