Jump to content

E6420 : HDMI Woes


kckustomac

Recommended Posts

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

 


 

 

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

  • Moderators

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

  • Administrators

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

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

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

×
×
  • Create New...