Jump to content
PayPal donations: [email protected] ×
Hervé

Enabling DVI/DP/HDMI and increasing VRAM with Intel Haswell/4th gen HD4200/4400/4600/etc. iGPU

Recommended Posts

Last updated: 28 Mar 2020
 
This guide is a follow-up to similar work previously posted by EmlyDinesh for HD3000 and HD4000. It is based on the excellent research work published by many other well-known Hackintosh gurus such as Pike R Alpha, Toleda, RampageDev, Rehabman and several others (whose name eludes me and for which I apologize) and for which they must be once again thanked. Their work is readily available through a Google search with keywords that include "Azul", "Framebuffer", "HD4x00", etc (brain usage is expected here). I did not do anything other than study this existing literature and experiment with the Intel HD4600 fitted to my Dell Latitude E6440 laptop (SMBIOS MBP11,1 Profile) in order to gain DVI output off an E-Port Plus/PRO2X docking station/port replicator, having previously obtained HDMI output through a binary patch handed over to me (a patch I wanted to understand). The E6440 comes fitted with a VGA port + a HDMI port. This being stated, the information below should be considered as that -experimentation results- and guidance for experimentations for those seeking to gain DVI, DP or HDMI video output on their Haswell GPU-based Hackintosh.

Haswell integrated GPUs include Intel HD (4th gen)/HD 4200/HD 4400/HD 4600/HD P4600/HD P4700/HD 5000 as well as Iris 5100/5200. In OS X, display ports are managed by the framebuffer (FB) kext and for the Haswell family, we're talking about AppleIntelFramebufferAzul.kext (Azul FB). The Azul FB binary file contains various tables associated with each layout, each being identified by its own id (layout-id/ig-platform-id/ etc.) and, usually, about 7 x 16bytes long (I'm not 100% certain of the specific table length and end for each layout). These FB layout ids are the values that most of us have to inject in DSDT or bootloader setup to obtain full graphics acceleration, for instance 0x0600260a for laptops or 0x0300220d for desktops.
 
1) Azul framebuffer analysis / layout ids
 Let's look at a few tables of El Capitan 10.11.3 Azul FB kext (latest at time of writing), including those specific to the above 2 ids. Using a Hex editor, they're found at offsets 48xxx/49xxx. The 1st 4 x bytes identify the layout id and the rest includes data such as number of ports, VRAM allocation, framebuffer index, port index, connector types, activation delays, etc..
 
The layout details are available in the attached extract:
EC_10.11.03_AzulFB_layouts.zip
 
The 1st layout is found at Offset 48CD0:
0000 060C 0003 0303 0000 0004 0000 0001          layout id
0000 F000 0000 0040 9914 0000 9914 0000          VRAM allocation
0000 0000 0000 0000 0000 0800 0200 0000          framebuffer index / port number

3000 0000 0105 0900 0400 0000 0400 0000          ??? (priority?)
0204 0900 0008 0000 8200 0000 FF00 0000          connector-type
0100 0000 4000 0000 0400 0000 0000 0700          activation delay
0400 0000 0000 0000 0000 0000 0000 0000
...
...
...
 
At Offset 49130, we have:
0600 260A 0103 0303 0000 0002 0000 3001          layout id (usual layout for mobile HD4600 Hackintosh)
0000 6000 0000 0060 D90A 0000 D90A 0000          VRAM allocation
0000 0000 0000 0000 0000 0800 0200 0000          framebuffer index / port number

3000 0000 0105 0900 0004 0000 8700 0000          ??? (priority?)
0204 0900 0004 0000 8700 0000 FF00 0000          connector-type
0100 0000 4000 0000 0F00 0000 0101 0000          activation delay
0400 0000 0000 0000 0E00 0000 0000 0000
...
...
...
 
At Offset 492F0, we have:
0300 220D 0003 0303 0000 0002 0000 3001          layout id (usual layout for desktop HD4600 Hackintosh)
0000 0000 0000 0060 9914 0000 9914 0000          VRAM allocation
0000 0000 0000 0000 0105 0900 0004 0000          framebuffer index / port number

8700 0000 0204 0A00 0004 0000 8700 0000          ??? (priority?)
0306 0800 0004 0000 1100 0000 FF00 0000          connector-type
0100 0000 4000 0000 0204 0000 0101 0000          activation delay
0400 0000 0000 0000 0E00 0000 0000 0000
...
...
...
 
What interests us here, in the matter of display output ports, are the above highlighted parameters.
 
* In terms of framebuffer indexes, they appear to range from 0 to 3, depending on mobile or desktop GPU version, 0 looking reserved for built-in LCDs. We also notice that each layout caters for 3 x ports only, each framebuffer/port-related line beginning with a similar form made of a pair of bytes:

  • 0000 ... for framebuffer #0 / port #0
  • 0105 ... for framebuffer #1 / port #5
  • 0204 ... for framebuffer #2 / port #6
  • 0306 ... for framebuffer #4 / port #7

* In terms of "priority", I've read that the byte right after the FB index apparently operates in conjunction with the activation delay: when 2 ports have an identical "priority" value, the port with the highest delay takes precedence, thereby disabling the other. If ports have their own unique "priority", they will be all enabled/available. I'll have to try to hook DVI + HDMI at the same time to confirm this behaviour.
 
* In terms of connector-type, there are several known values:

  • 0100 0000 for VGA
  • 1000 0000 for VGA
  • 0200 0000 for LVDS/eDP (built-in LCD of laptops)
  • 0400 0000 for digital DVI
  • 0002 0000 for analog DVI
  • 0004 0000 for DP
  • 0008 0000 for HDMI

 

When using the vanilla Azul FB kext, my E6440 reports the following in IOReg:
[email protected] (built-in LVDS display showing attached to this)

  • port-number: 0x0
  • connector-type: 02 00 00 00

[email protected]

  • port-number: 0x5
  • connector-type: 04 00 00 00

[email protected]

  • port-number: 0x6
  • connector type: 04 00 00 00

 

One could easily imagine a direct translation of the FB index + its adjacent byte in the layout tables with the display port number as reported in IOReg; that'd be incorrect, as stated in the existing literature. If, indeed, the layout id tables show pairs "00 00" for port #0 and "01 05" for port #5, one would quickly notice that pair "02 04" translate to port #6 and pair "03 06" to port #7.
 
 
2) HDMI and DVI display output
When experimenting with my mobile HD 4600-based Latitude E6440, no HDMI output was obtained OOB with the vanilla Azul FB kext. In fact, the laptop immediately crashed the moment a HDMI cable was hot-plugged. It would not even boot with a HDMI cable plugged in.

However, HDMI works perfectly after applying the binary patch to the kext where the hex string 01050900 00040000 87000000 is replaced by 01051200 00080000 87000000.
 
We can see that this patch modifies:
a) the (priority?) byte right after id
2) the connector type
 
In IOReg, the HDMI display showed attached to FB index #1 with port-number 0x5 and connector-type 0008 0000.

We can see that, in the vanilla kext, FB indexes #1 and #2 of layout id 0x0600260A use the same (priority?) byte after the id, the same activation delay and the same connector-type.
 
Building on the gathered technical information from the literature and the above observations, I tried to enable the DVI port off my docking station to use a 2nd DVI screen (lack of VGA support oblige). I first applied the following patch to layout id 0600260A located at offset 49130, keeping the above HDMI patch untouched.
before: 02040900 00040000 87000000 FF000000
after:   02040900 00020000 87000000 FF000000
 
This failed to enable DVI output off my E-Port Plus. I then tried to adjust other parameter such as (priority?) byte after id and activation delay, to no avail. Keeping in mind the availability of framebuffer index #3, I then applied the following patch, again leaving the HDMI patch untouched:
before: 02040900 00040000 87000000 FF000000
after:   03060900 00020000 87000000 FF000000
 
This proved successful and brought me DVI output off the E-Port Plus/PRO2X :). However, HDMI appeared broken as system froze as soon as HDMI cable got plugged in.
 
After several adjustments of the (priority?) byte after id, HDMI and DVI outputs are obtained when the byte is set to 12 for both ports. This makes for the following Azul FB binary patch:
 
At Offset 49130, patch vanilla table:
0600 260A 0103 0303 0000 0002 0000 3001
0000 6000 0000 0060 D90A 0000 D90A 0000
0000 0000 0000 0000 0000 0800 0200 0000     ; FB index #0/port #0, connector-type LVDS
3000 0000 0105 0900 0004 0000 8700 0000     ; FB index #1/port #5, connector-type DP
0204 0900 0004 0000 8700 0000 FF00 0000     ; FB index #2/port #6, connector-type DP
0100 0000 4000 0000 0F00 0000 0101 0000
0400 0000 0000 0000 0E00 0000 0000 0000
 
to:
0600 260A 0103 0303 0000 0002 0000 3001
0000 6000 0000 0060 D90A 0000 D90A 0000
0000 0000 0000 0000 0000 0800 0200 0000     ; FB index #0/port #0, connector-type LVDS
3000 0000 0105 1200 0008 0000 8700 0000     ; sets connector-type to HDMI
0306 1200 0002 0000 8700 0000 FF00 0000     ; sets FB index to 3/port #7 and connector-type to DVI
0100 0000 4000 0000 0F00 0000 0101 0000
0400 0000 0000 0000 0E00 0000 0000 0000
 

E6440_DVI_output.jpg 
 
That exact same patch is also applicable to Yosemite and Mavericks as well as Sierra.

 

 

3) VGA display output
VGA output is simply not supported on Haswell iGPUs to the exception of HD4400 with which such output is known to work OOB on some platforms. HD4400 the only iGPU of the Haswell family to present such behaviour. There is no patch, no workaround, no solution for VGA output for the others.

 

 

Edit: 28 Mar 2020

- - - - - - - - - - - - -

Thread cleaned up to retain only the useful info.

 

  • Like 7

Share this post


Link to post
Share on other sites

For DP output, framebuffer #2 (port #6) should be kept (as expected). The prority (?) byte just needs to be set to 12.

 

The patch is as follows:

0600 260A 0103 0303 0000 0002 0000 3001
0000 6000 0000 0060 D90A 0000 D90A 0000
0000 0000 0000 0000 0000 0800 0200 0000     ; FB index #0/port #0, connector-type LVDS
3000 0000 0105 1200 0008 0000 8700 0000     ; sets connector-type to HDMI

0204 1200 0004 0000 8700 0000 FF00 0000     ; sets DP priority(?) to 12
0100 0000 4000 0000 0F00 0000 0101 0000
0400 0000 0000 0000 0E00 0000 0000 0000

  • Like 1

Share this post


Link to post
Share on other sites

I've noticed that, since 10.12.3 (can't say for earlier Sierra versions), the DVI patch no longer seems to work for DVI secondary output. My DVI connected screen remains undetected after startup (repeated behaviour off 2 x different types of docking station/port extender). I can only get DVI output by booting my laptop with lid closed, i.e. with single display output to DVI.

 

Edit: 05 Sep2018

DVI output recovered in Sierra and High Sierra with AppleGraphicsDevicePolicy kext patch as described on p5.

Share this post


Link to post
Share on other sites

Further to fresh experiments with VRAM allocation, I can confirm that the 8th byte of the 2nd line of Azul framebuffers/layouts as displayed above (in 8 groups of 4 bytes per line) is for VRAM allocation and can be set as follows:

  • 40 -> 1024MB
  • 60 -> 1536MB
  • 80 -> 2048MB

 

In my case, changing the Azul FB #12/layout 0x0a260006 from this:

0600 260A 0103 0303 0000 0002 0000 3001

0000 6000 0000 0060 D90A 0000 D90A 0000

 

to this:

0600 260A 0103 0303 0000 0002 0000 3001

0000 6000 0000 0080 D90A 0000 D90A 0000

 

increased VRAM from 1536MB to 2048MB.

Share this post


Link to post
Share on other sites

Found a fix here at InsanelyMac (thx @lubeats) for loss of DVI 2nd screen; patch of AppleGraphicsDevicePolicy kext:

Find:       BA05000000
Replace by: BA00000000

 

With this patch in place, I recovered DVI output off my docking station in Sierra 10.12.6 and High sierra 10.13.6.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hey @Hervé I told You that info in my post in InsanelyMac here. I discovered it for curiosity in a config.plist where nobody mention that with it We could get output video port for DVI and HDMI. It works in mojave beta too but audio HDMI doesn't works.

 

 

Share this post


Link to post
Share on other sites

Indeed. I did read a little further about patching the AppleGraphicsDevicePolicy  kext and found out it was a bypass for some checks (details elude me now, it was a quick read).  So I gave it a try as a fix for my 2nd screen issues and it worked. I've not tried Mojave on the E6440 yet but 10.14 comes out on Monday so it's just a few days to wait for the new OS installation package... The usual Azul patch certainly works in High Sierra 10.13.6 (alongside the AppleGraphicsDevicePolicy patch) for HDMI audio...

Share this post


Link to post
Share on other sites

I've been playing a little more on the multiple external displays arrangement and modified the Azul FB patch for dual DVI outputs:

Dual-DVI_patch.jpg

 

I can then hook 2 x DVI screens off an E-Port Plus/PRO2X docking station (the wide model with 2 x DVI + 2 x DP ports):

3_Displays_HD4600.jpg

 

However, initially, I reproduced the DVI black screen issue I experienced at home when attaching DVI + HDMI displays to my E6440:

IMG_1744.jpg

 

IMG_1746.jpg

 

The screen that went black was the 19" Dell 1908WFP attached to DVI output #1. @1440x900, it's got a lower max. resolution than the 21,5" Full HD Dell P2211H @1920x1080 attached to DVI output #2.

 

So I thought the issue could be related to resolution. After various adjustments, I found that, in order to obtain video output on both external displays, the larger screen must not be set to a resolution higher than the highest of the smaller screen. Otherwise the screen with lowest capacity goes black or displays snow. But I cannot select just any lower res, some remain incompatible with the smaller screen! 🙄

 

I could therefore settle for resolutions both screens had in common such as @1360x768/@1280x960/@1024x768 or set the smaller screen to its max. res. @1440x900 and the larger screen @1360x768:

1st_DVI_screen.jpg  2nd_DVI_screen.jpgIMG_1749.jpg

 

It would also appear that combinations and/or ratios of resolutions applied to the screens may impact video output. For instance, if both screens are set to 1360x768 which is 16:9, I can set the small screen to 1440x900 which is 16:10 and retain full video outputs. I can then set the large screen to 1280x960 which is 4:3 without any impact. If I further reduce the large screen to 1024x768 which is still 4:3, small screen goes black. If I then set the large screen to 1280x1024, I get snow on the small screen. This snow will remain when I return the large screen to resolutions that previously work. If I then set both screens to 1360x768, video output resumes on both screens and I can then set the large one to 1280x1024 without any loss of video! Can make that one out...

 

NB: If I swap DVI outputs and place the large screen on DVI #1 and the small screen on DVI #2, it's the large screen that goes black.

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...