kckustomac Posted February 14, 2017 Share Posted February 14, 2017 So I have an E6420 no optimus, low-res (specs in signature L01), and everything is working great...until I plug in external monitor to the HDMI port....then all hell breaks loose. after plugging in hdmi -- native laptop monitor is underscanned. I change the display preferences to turn off mirroring / use hdmi monitor as extra display, restoring built-in lcd resolution. Upon reboot, built-in lcd is black and hdmi display is the only detected display. Shutdown, unplug hdmi cable, reboot and built-in lcd is black screen ... only way i can get a display is by plugging in hdmi cable to external monitor. I caught a screenshot that sort of highlights the issue during same session of hot-plugging the hdmi cable...notice that the resolution is 1920x1080 for the built-in display in system info but of course it can only output 1366x768 E6420-L01__CFG.zip I tried the sierra bootpack from jake's infamous guide (esp since it was patched dsdt for a23 bios) but that didn't even get me to the install screen...I am instead using a LoRes DSDT from others, not sure the exact source, but somewhere on this site. Anyways, I posted my efi directory which contains everything, config.plist / dsdt.aml and native/clean acpi dumps...lemme know if this issue has been solved or how I can go about troubleshooting, thank you!!! Link to comment Share on other sites More sharing options...
Moderators Jake Lo Posted February 14, 2017 Moderators Share Posted February 14, 2017 You set you external monitor as the primary instead of being extended. When booted with HDMI, with the screen black, have you tried selecting Fn+Insert a couple of times? This will increase the brightness. Fn+F3 will decrease. Link to comment Share on other sites More sharing options...
Administrators Hervé Posted February 14, 2017 Administrators Share Posted February 14, 2017 HDMI video output is normally supported OOB on the E6x20 Series. Try to temporarily disable the SNB patches on you Clover config.plist. They look Ok but they apply to all instances of the Hex sequences, not just to the series of ports under 01020400 10070000 10070000. If it works Ok, then we'll known whether it's the SNB patches or, say, the DSDT. I could not see anything wrong under the IGPU section of your DSDT. Link to comment Share on other sites More sharing options...
kckustomac Posted February 15, 2017 Author Share Posted February 15, 2017 i did get this one to work, now i'm fighting the L02 (Optimus lo res) ... FOR SOME REASON (I emphasize this because It seems unrelated) but, for some reason, it was the applehdaidt patches from jake that, once applied, caused issues with the HDMI on this particular model, and it is probably due to the dsdt not necessarily compatible with my configuration + the 4 different clover patches??? (which to enable/disable jake?) ...but i can't be sure of that. I AM sure that with the applehdaidt.kext installed in L/E and root wheel scripts ran, the hdmi became far more unreliable and buggy...you're right herve it is working as desired oob.... ...so i ended up just keeping oob and then using wern's hda method of zeroing out layout-id and applying applehda to sle, but havent tested if this will survive updates...i doubt it will since a vanilla could replace the applehda kext but for now, at least i have A fool-proof method of everything working on this model...thanks for your guys' help!!! Link to comment Share on other sites More sharing options...
Administrators Hervé Posted February 15, 2017 Administrators Share Posted February 15, 2017 The HDMI patch usually applied to HD3000 (for HDMI audio) may indeed not be applicable to the nVidia model. Link to comment Share on other sites More sharing options...
kckustomac Posted February 15, 2017 Author Share Posted February 15, 2017 true, it was almost necessary for the hd3000, until i tried wern's applehda...only problem is , it requires zeroing layout-id in dsdt...i have two overall questions for anyone : When opening , or failing to open , a dsdt.aml in maciasl , does maciasl use the host-machine's acpi tables in any way ? or does it act as an independent UB application that contains the compiler within itself...it seems like different machines open dsdt's differently...but idk. Previous to my membership at osxlatitude , i NEVER used dsdt's ... just injected kexts and patches. Other than the benefits of speed / native compatibility, why is there less support for dsdt-less methods. Since ACPI requires a lot of documentation, C-experience, and DSDT only suits the needs of a specific machine and specific hardware components, and even based on a certain firmware/bios version. I've gotten close to booting without DSDT, but i seem to be failing on USB injection, having only tried USBinjectall and USBinjector (both need info plist patching of course) ... any thoughts? Link to comment Share on other sites More sharing options...
Recommended Posts