Jump to content
InsanelyMac Forum
iWin32

[GUIDE] How to enable custom resolution for first-gen Intel HD Graphics (0042:8086 and 0046:8086)

Recommended Posts

How to Enable Resolution on Intel HD Graphics (0046:8086 and 0042:8086)

 

Background Info:

It has been said since the dawn of time: “Ye who build a Hackintosh must select a Graphics Card that ye can find in a real Mac to ensure 100% compatibility.” However, it appears a very rare exception is ye…I mean the infamous Intel HD Graphics. These first-gen integrated Graphics Cards found on Core iXXX processors are the first to use the new I/O design, integrating the Northbridge into the CPU itself. The Intel HD Graphics chips have been used in real Macs before, like the Mid-2010 MacBook Pro. The problem: Every Mac that has the integrated Graphics chip also has a dedicated Graphics Card, like the NVIDIA GeForce GT 330M on the same MacBook Pro model. Therefore, it’s not that Apple didn’t write drivers for the Intel HD Graphics, but their drivers are, well, buggy on PCs, resulting in either a frozen or blank screen once the framebuffer Kext loads.

 

People have worked out a way to enable partial Quartz Extreme in Snow Leopard 10.6.7, but even that is very buggy. Try to launch anything Full Screen, get greeted with a surprise Kernel Panic. There was no hope as to how to get full resolution…until now!

 

Manor had thought he had found a way to enable full resolution on Intel HD Graphics, but what he didn’t realize was that his VESA mode tables in his Video BIOS supported his resolution. Everyone that his “fix” worked for them also had it supported in their Video BIOS. Everyone else likely had the maximum of 1024x768 in their mode tables, and therefore couldn’t work.

 

Since then, people had suggested patching the Video BIOS on the fly with the Resolution module… a module based off of the 915resolution Linux hack that also patches NVIDIA and some ATI cards. However, by itself, it doesn’t do a thing. Yet, a recent patch to the module enables support for the Intel HD Graphics! This isn’t a simple one-for-all compile, however. Why? The patch is full of hacks, and it requires you to insert your DTD, an 18-byte sequence extracted from your EDID, into the source code directly. You need a little bit of programming knowledge, but it’s so trivial that just about anyone with little to no programming knowledge (like me) could patch.

 

So, what do you need to get this patch to work?

 

Requirements:

  • Access to Mountain Lion with XCode installed and network access (to compile Chameleon)
  • Access to Windows
  • Extracted EDID of the computer in question UPDATE: If you want, you can try RemC's module in this post; it should be universal and not require any source code patching on your part. Look at the second post: http://www.insanelym...6/#entry1877529
  • A flash drive (optional, even an old 256MB flash drive would do)

You’ll also need to download these tools:

  • DTD Calculator – http://www.clevertec...roductsfree.htm
  • Attached Resolution source code IMPORTANT UPDATE (4/4/2013): If you plan on enabling QE/CI (see below), don't bother with any form of the resolution module. The patched framebuffer will allow custom resolution without the resolution module. The Resolution module is only needed if you want custom resolution on your boot screen. Otherwise, don't mess with it as it may cause distortions. The guide is below is kept for legacy purposes/for those who want to create their own Resolution Module.

How to Extract your EDID:

This is pretty self-explanatory in another thread: http://www.insanelym...s/#entry1392033

 

Go to Solution B. I prefer using the Windows way, but the link to the utility there is dead. Go here: http://www.eldim.fr/...lite-free-tools and click the link that reads “EDID Viewer utility”. Please note, though, and I cannot stress this enough: THIS NEEDS TO BE RUN ON THE COMPUTER WITH INTEL HD GRAPHICS INSIDE. THIS WILL EXTRACT THE EDID VALUE FROM YOUR MONITOR, SO YOU NEED TO RUN IT ON THAT COMPUTER ONLY! (Sorry for shouting, but EDID varies from monitor to monitor, even LCD monitors from the same laptop model with the same max resolution. Using someone else’s EDID is like using someone else’s DSDT.aml file. Thus, run only on your computer with Intel HD Graphics on it.)

 

Save your EDID raw data somewhere, or copy your EDID to your clipboard if you’re using the same computer. Now that you’ve got that saved, you’re ready to go to step 1.

 

Step 1 – “Convert” EDID to DTD:

I put the word convert in quotation marks because we really aren’t converting it. All we’re doing is extracting specific 18 bytes from the EDID raw data. Launch DTD Calculator and a text editor. For our purposes, Notepad will do. When you copy the raw data from ELDIM, it’ll look something like this:

0x00 00 FF FF FF FF FF FF 00 30 E4 AC 02 00 00 00 00	
0x10 00 14 01 03 80 22 13 78 0A C1 25 9D 5F 5B 9B 27	
0x20 19 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01	
0x30 01 01 01 01 01 01 12 1B 56 78 50 00 0E 30 20 20	
0x40 24 00 58 C2 10 00 00 19 00 00 00 00 00 00 00 00	
0x50 00 00 00 00 00 00 00 00 00 00 00 00 00 FE 00 4C	
0x60 47 20 44 69 73 70 6C 61 79 0A 20 20 00 00 00 FE	
0x70 00 4C 50 31 35 36 57 48 32 2D 54 4C 51 42 00 C1	

 

You need to have the raw hex data in a single line with only a space to separate them. Using mine, it then should read like this:

 

00 FF FF FF FF FF FF 00 30 E4 AC 02 00 00 00 00 00 14 01 03 80 22 13 78 0A C1 25 9D 5F 5B 9B 27 19 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 12 1B 56 78 50 00 0E 30 20 20 24 00 58 C2 10 00 00 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE 00 4C 47 20 44 69 73 70 6C 61 79 0A 20 20 00 00 00 FE 00 4C 50 31 35 36 57 48 32 2D 54 4C 51 42 00 C1

 

In DTD calculator, click the Interpret EDID tab, and paste the resulting string in there. And then click Interpret EDID.

 

It should say the DTD on the bottom right. Double click it. You may get a warning that reads “Entered DTD and Generated DTD don’t match”. Ignore it. To make sure you’ve got it right, or if there is more than one, the right should have a value under H Active Pixels and V Active Lines. These values should be your resolution.

 

Now click the Calculation tab. On the bottom you’ll see the calculated DTD. Click in the text box. Press Ctrl+A to select the text and Ctrl+C to copy it to the clipboard. This is the DTD. Here is my DTD as an example:

12 1B 56 78 50 00 0E 30 20 20 24 00 58 C2 10 00 00 18

 

Paste it into a notepad window and save it as a text document. Make sure you’ll be able to access this on the machine where you’ll be compiling Chameleon.

 

Speaking of which, we now need to move onto the next step, which happens to be compiling Chameleon.

 

Step 2: Compile Chameleon with Modified Resolution Code

 

Just like its mother, 915resolution, the Resolution module will modify our VBIOS on the fly to allow us to select a different resolution from the VESA tables. Therefore, before we compile, we need to modify the code. Thankfully (with many thanks to InsanelyMac User and Chameleon developer orlian, as well as Chameleon developer dmazar), we can patch use already modified code. However, we still need to replace the present DTD with ours. Remember, as this is from EDID, it will vary from monitor to monitor. But first, we need to download and clean up Chameleon’s source code. To do so, download XCode on Mountain Lion, and install command line tools. You can use an already existing hackintosh with internet, a real Mac, or, like me, use a VMware virtual machine.

 

Once you have XCode installed, open a terminal window (don’t freak out if you’ve never used command line before; these commands are safe) and type the following commands:

mkdir chameleon-imod
cd chameleon-imod
svn co http://forge.voodooprojects.org/svn/chameleon/trunk/
cd trunk
make clean

 

If all goes well, there should be a folder called “chameleon-imod” in your home folder. In there, should be only one folder called trunk. Inside that folder should be all sorts of file, including an XCode project called Chameleon. Navigate further into i386 > modules. This contains the source code for the individual Chameleon modules. Delete the folder called Resolution and empty the trash. Then, replace it with the attached Resolution source code.

 

Resolution.zip

 

Now, in the Resolution folder, open the file called 915resolution.c. This will open an XCode Window and navigate to line 32. The code should be:

	 map = open_vbios(CT_UNKNOWN);
 // if(map)
	 {
			 unlock_vbios(map);
	 char* bytes = (char *)VBIOS_START;
	 int patchlocation = 0x0254;
	 verbose("Addr: %X Before patch: %x - ", patchlocation, bytes[patchlocation] );
	 bytes[patchlocation] = 0x8A;
	 verbose("after patch: %x \n", bytes[patchlocation++] );
	 bytes[patchlocation++] = 0x25;
	 bytes[patchlocation++] = 0xA0;
	 bytes[patchlocation++] = 0x20;
	 bytes[patchlocation++] = 0x51;
	 bytes[patchlocation++] = 0x84;
	 bytes[patchlocation++] = 0x1A;
	 bytes[patchlocation++] = 0x30;
	 bytes[patchlocation++] = 0x30;
	 bytes[patchlocation++] = 0x40;
	 bytes[patchlocation++] = 0x36;
	 bytes[patchlocation++] = 0x00;
	 bytes[patchlocation++] = 0x30;
	 bytes[patchlocation++] = 0xBE;
	 bytes[patchlocation++] = 0x10;
	 bytes[patchlocation++] = 0x00;
	 bytes[patchlocation++] = 0x00;
	 bytes[patchlocation++] = 0x1E;

 

This is the portion we need to modify to match our DTD. Every byte XX in our DTD is read by the source code as bytes[patchlocation++] = 0xXX;

 

Therefore, in my DTD code, 0x8A becomes 0x12, 0x25 becomes 0x1B, 0xA0 becomes 0x56, etc.

 

Once that’s modified, save it and exit XCode. We’re now ready to compile Chameleon. Navigate back to the terminal window and type:

 

make

 

I know it’s a pain we have to compile all of Chameleon when we only need to compile the resolution module, but we can’t just type make in the directory of the resolution module source code; I’ve tried it and it doesn’t do anything.

 

Once that’s taken care of, navigate back up to the trunk directory, and in the sym folder, should be the i386 folder of Chameleon binaries. If you’re going to do step three, copy this back to a Windows computer. I recommend compressing it into a zip file first if you do that. If not, go straight to step 4.

 

Why am I suggesting you don’t have to do step 3?

 

Step 3: Install Chameleon to a test flash drive (optional)

This is not required, but I do recommend you do this. Why? There isn’t any reason to believe you can’t simply copy the resulting Resolution.dylib to /Extra/modules/ folder. However, if something went wrong and the computer can’t boot due to wrong resolution/poor timings, the resolution module is only present on the Flash Drive and you can simply reboot off of the hard drive without issues and try compiling again. If you skip step 3, though, you’re stuck until you boot without the module. Therefore, I recommend you install Chameleon to the flash drive for testing purposes. Once you go into Windows, I’ll be showing you a somewhat new way to install Chameleon using Clover’s Win32 tools.

 

Download the package called Win_USBTools-Fat32_Clover_v2_rL954.zip from here: http://www.osx86.net..._efi_tools.html

 

Extract the archive inside there called USBTools-Boot1f32.zip. Be sure to back up everything on your flash drive that you need. We’re going to format it with the tool HPUSBFW.EXE. Run it as administrator, select your flash drive, and tick quick format. Make sure it’s set to format it to FAT32. Click start. Confirm you want to continue and let it do its thing.

 

Once that’s done, and this is important, unplug it (don’t use safely remove hardware), and plug it back in.

 

Next, open a command prompt in the extracted directory as administrator, and type:

 

BootUSB.bat X:

 

Where X is the drive letter of your flash drive. If it completes without errors, do the same replug method as before.

 

Finally, extract our compiled binaries. Copy the file “boot” to the root directory of the flash drive and create an Extra folder. If you need to copy any contents from your own Extra folder (especially true if FakeSMC.kext is inside /Extra/Extensions and not /System/Library/Extensions), do so now. However, be sure to run create a modules folder inside the Extra folder and copy “Resolution.dylib” in that modules folder.

 

Step 3a: Testing

Once that’s done, reboot off of the flash drive. If there was a theme inside your Extra folder, the VBIOS patch should be noticeable from the GUI. If there isn’t a theme installed, or the resolution still appears form the GUI as 1024x768, type at the boot prompt “?video” (without quotes) to make sure that the resolution is listed in the VBIOS. If it isn’t listed there, something went wrong. It should patch an already present resolution. In my case, it was 800x600.

 

If your resolution is listed, try typing “Graphics Mode”=”XxYx32” (WITH Quotes, where X and Y are your resolution values, i.e. 1366x768x32) with any other boot flags you need to successfully boot OS X. If all goes well, you should see full resolution. If something looks funny, but the resolution is correct, then the timings are wrong. Make sure that the DTD was copied correctly in step 2 and try compiling again.

 

If, however, it isn’t listed, boot using the flags “-v Wait=Yes” (without quotes), and before it loads OS X, you’ll see a screen with all startup logs by Chameleon. Scroll down (With theme/GUI, use arrow keys, without theme, space bar to go to next page, p to go to previous page) to where it says “Resolution.dylib by Unknown loaded”. This is the log of Chameleon loading the resolution module. If it shows any errors, take a screenshot of the log and feel free to upload an image here.

 

If you’ve got your full resolution within Mac OS X, you’re ready to install the Resolution module to your Chameleon installation.

 

Step 4: Install the Resolution Module to your existing Chameleon/OS X installation

Copy the file Resolution.dylib from your flash drive (or your compiled binary extracted from the zip folder) to /Extra/modules. If there isn’t a “modules” folder in the /Extra folder, create it.

 

Also, be sure to modify org.chameleon.Boot.plist to have these lines in:

 

 

<key>Graphics Mode</key>
<string>1366x768x32</string>

 

 

Of course, be sure to change the resolution to match your own if it’s different.

 

Once that’s done, reboot and you’ll have your resolution in OS X. If something goes wrong, use the same steps in step 3a to debug the error.

 

Step 5: Enabling Acceleration in Mac OS X

Mountain Lion TBD. UPDATE (2/5/2013): Mountain Lion now is capable of enabling Core Image on our Graphics Card. Still no Quartz Extreme, but if you try it out, check out Part 2 in this post: http://www.insanelym...s/#entry1885544 Thanks goes to GhostRaider for the guide, and Mehdymehdy for his discovery!

MAJOR UPDATE (3/10/2013): We have made history: a patch for the Mountain Lion Framebuffer was made, and it works now on our machine. Look at this thread: http://www.insanelym...-fixed-sl-1068/ and this post: http://www.insanelym...20#entry1895588 Special thanks to verteks and warraisraw for their discoveries!! :)

 

However, if you don’t have a problem using an older version of OS X, follow these guides to enable partial QE/CI in Snow Leopard:

 

http://www.insanelym...0/#entry1504066

 

http://www.insanelym...d/#entry1827443

 

And that’s it! I hope this guide has been of use to you, and that you’ll be able to use your Intel HD Graphics once and for all!

 

Special Thanks To:

Share this post


Link to post
Share on other sites
Advertisement

Thanks for the detailed guide. I started converting my Acer Aspire 5742Z into a hackintosh last week. It contains an Intel P6100 processor (Arrandale) with integrated Intel HD Graphics GPU (Ironlake). I have been reading a lot on the different forums and found out about the recent development in this thread: http://forum.voodoop...topic,2754.html

 

Using orlian's code and some changes I now have my native 1366x768 resolution in ML instead of the 1024x768, finally!

 

The code you've posted above is for most people probably not enough, because their video bios won't be unlocked.

Orlian has hacked in some code to do that and then it works. However instead of getting your EDID through Windows or even Linux is annoying and unnecessary because the Resolution module already has code built-in to do just that! I have changed the code posted above with the following code that extracts the first valid DTD from the EDID and use that to patch the video bios.

 

vbios_map * map;

map = open_vbios(CT_UNKNOWN);
if(map)
{
 unlock_vbios(map);

 char* edidInfo = readEDID();
 struct EDID* edid = (struct EDID*)edidInfo;
 unsigned char* block = (unsigned char*)edid + DETAILED_TIMING_DESCRIPTIONS_START;
 for (int i = 0; i < 4; i++, block += DETAILED_TIMING_DESCRIPTION_SIZE)
 {
   if ((block[0] != 0x00) || (block[1] != 0x00) ||
     (block[2] != 0x00) || (block[4] != 0x00))
     break;
 }
 memcpy((char*)(VBIOS_START + 0x254), block, DETAILED_TIMING_DESCRIPTION_SIZE);
 free(edidInfo);

 set_mode(map, x, y, bp, 0, 0);

 relock_vbios(map);

 close_vbios(map);
}

 

It is all a bit hacky but hopefully this works for most of us. I haven't been able to find any information about the GMA video bios, so I have hardcoded the magic 0x254 offset that orlian uses. Possibly map->mode_table - 0x14 is a better alternative for VBIOS_START + 0x254 but that's just a guess. It works for me but it might not for someone else. Also, this code could be improved for EDID's with multiple valid DTD's. In that case the resolution should be decoded and the DTD with the highest should be used. I read that this doesn't happen often though.

 

I have attached a tar ball with my Resolution.dylib so people don't have to do all the above but can simply copy it into /Extra/Modules and have native resolution. It also contains my 915resolution.h and 915resolution.c they are the same as orlian's with the above fix applied.

resolution_patch.tar.gz

Share this post


Link to post
Share on other sites

Thanks for the detailed guide. I started converting my Acer Aspire 5742Z into a hackintosh last week. It contains an Intel P6100 processor (Arrandale) with integrated Intel HD Graphics GPU (Ironlake). I have been reading a lot on the different forums and found out about the recent development in this thread: http://forum.voodoop...topic,2754.html

 

Using orlian's code and some changes I now have my native 1366x768 resolution in ML instead of the 1024x768, finally!

 

The code you've posted above is for most people probably not enough, because their video bios won't be unlocked.

Orlian has hacked in some code to do that and then it works. However instead of getting your EDID through Windows or even Linux is annoying and unnecessary because the Resolution module already has code built-in to do just that! I have changed the code posted above with the following code that extracts the first valid DTD from the EDID and use that to patch the video bios.

 

vbios_map * map;

map = open_vbios(CT_UNKNOWN);
if(map)
{
unlock_vbios(map);

char* edidInfo = readEDID();
struct EDID* edid = (struct EDID*)edidInfo;
unsigned char* block = (unsigned char*)edid + DETAILED_TIMING_DESCRIPTIONS_START;
for (int i = 0; i < 4; i++, block += DETAILED_TIMING_DESCRIPTION_SIZE)
{
if ((block[0] != 0x00) || (block[1] != 0x00) ||
(block[2] != 0x00) || (block[4] != 0x00))
break;
}
memcpy((char*)(VBIOS_START + 0x254), block, DETAILED_TIMING_DESCRIPTION_SIZE);
free(edidInfo);

set_mode(map, x, y, bp, 0, 0);

relock_vbios(map);

close_vbios(map);
}

 

It is all a bit hacky but hopefully this works for most of us. I haven't been able to find any information about the GMA video bios, so I have hardcoded the magic 0x254 offset that orlian uses. Possibly map->mode_table - 0x14 is a better alternative for VBIOS_START + 0x254 but that's just a guess. It works for me but it might not for someone else. Also, this code could be improved for EDID's with multiple valid DTD's. In that case the resolution should be decoded and the DTD with the highest should be used. I read that this doesn't happen often though.

 

I have attached a tar ball with my Resolution.dylib so people don't have to do all the above but can simply copy it into /Extra/Modules and have native resolution. It also contains my 915resolution.h and 915resolution.c they are the same as orlian's with the above fix applied.

 

Firstly, the patch attached to this thread already has orlian's hacks in it. The patch used the resolution source copied from the VoodooLabs post and I overwrote the existing 915resolution.c file with orlian's. The code in the OP was just to guide them into what they had to modify, not add to the existing code.

 

And, as to your patched version that reads EDID from the monitor before patching: I'll have to give it a try. It seems interesting and would render this guide outdated. I'll come back after I test it... which will likely be later tonight because I still have homework to do! (Welcome back to school, right? :P)

Share this post


Link to post
Share on other sites

Ah yeah I totally missed your Resolution.zip attachment...my bad!

 

Let me know if the above works for you and hopefully we can come up with some more stable patch that works for all Intel HD Graphics GPU's. It would be great to have some documentation on the GMA Video Bios but that seems difficult to get.

Share this post


Link to post
Share on other sites

Now typing in Mac OS X Mountain Lion with a lovely resolution... thanks to your module, RemC. However, just to be sure, as I also have 1366x768, let's see if someone else, who has a different resolution, can enable it within OS X. Nice work!

 

However, I will say one thing: I noticed a small bug in your code. It says VBIOS not patched when it clearly has patched it! Here's a log of what bdmesg says:

 

localhost:~ ricorobbins$ /Users/ricorobbins/Downloads/Chameleon\ Wizard.app/Contents/Resources/bdmesg | grep -A10 Resolution
Read HFS+ file: [hd(0,2)/Extra/modules/Resolution.dylib] 30676 bytes.
Module 'Resolution.dylib' by 'Unknown' Loaded.
Description:
Version: 0
Compat: 0
Resolution: 1366x768x32
core proc identified
Detected chipset/proc id (DRAM controller): 00448086
VBios: Other - unknown
vbios unlocked
Patching: Unknown - vbios not patched
Read HFS+ file: [hd(0,2)/Extra/modules/uClibcxx.dylib] 77808 bytes.
Module 'uClibcxx.dylib' by 'Unknown' Loaded.
Description:
Version: 0
Compat: 0
localhost:~ ricorobbins$

 

And for proof, I've attached a screenshot of my resolution.

post-529889-0-66899000-1357170914_thumb.png

Share this post


Link to post
Share on other sites

Nice one! What you've got is not really a bug (and it's also not coming from that bit of code I've added).

Your BIOS Type doesn't seem to be recognized and as a result the set_mode function is not doing anything in your case, hence the not patched message. I suspect orlian has a similar scenario and commented the set_mode function out in his 915resolution.c.

 

In my case my BIOS Type is detected as BT_1 and without the set_mode function it won't work for me.

Share this post


Link to post
Share on other sites

I didn't realize you wrote a guide to enable custom resolution for 1st Generation Intel HD Graphics! I will definately try this out over the next few days to report my findings with my Gateway laptop. Thank you! :smoke:

 

With a custom resolution, we may now be able to work on our hackintoshes comfortably and figure out QE/CI.

 

EDIT: 1366x768 is now possible on my laptop. Great work guys! :thumbsup_anim:

 

EDIT2: It seems that just downloading and putting RemC's Resolution.dylib in Extra/Modules folder gives the same result. It seems that his module might be universal? :huh:

post-620531-0-90280900-1357448728_thumb.png

Share this post


Link to post
Share on other sites

This is amazing guys. I appreciate everyone's hard work. I have Intel P6100 on a Sony Vaio PCG-71312L laptop. Can't wait to get this bad boy up and running

Share this post


Link to post
Share on other sites

thanks for this! :king:

I tried this method many times but i've got same resolution of 1024x768... I install iAtkos L1 10.7.1 Lion..

i tried to boot in USB as step 3 and 3a indicated, and type "-v Wait=Yes" my chameleon log says:

 

 

Module 'Resolution.dylib' by unkown loaded

Description:

Version:0

Compat:0

Parse Edid: Descriptor block 0 is timing descriptor Best mode: 1366x768x32

getResolution: 1366x768x32

core proc identified

Detected chipset/proc id (DRAM controller): 00448086

VBIOS: OtherStarted mode table scan at: 0xC0010

Ended mode table scan at: 0xC0269

Table size: 0x24

, BT_1

bios unlocked

Addr: 254 Before patch: 0 - after patch: 36

 

Finished Patching at C0000 locking bios

best mode:1366x768x32

 

And then it boot up lion with 1024x768 resolution.. :wallbash:

 

How can i fix this? Please Reply... :help:

Share this post


Link to post
Share on other sites

UPDATE!!

 

I JUST COPY RemC's Resolution.dylib to my module folder and TADAHH!!! IT WORK LIKE A CHARM!! THANKS TO ALL OF YOU GUYS!!! :thumbsup_anim:

I am now typing this into my 1366x768 Display Hakinstosh laptop! YEAH!!!

post-1112219-0-22790300-1357554806_thumb.png

Share this post


Link to post
Share on other sites

Hi all,

I'm trying to use this hack but I got stuck with 1280x720 res.

 

 

Module 'Symbols.dylib' by 'Chameleon' Loaded.

Description: Chameleon symbols for linking

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/klibc.dylib] 44252 bytes.

Module 'klibc.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/Resolution.dylib] 30676 bytes.

Module 'Resolution.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Resolution: 1024x768x32

core proc identified

Detected chipset/proc id (DRAM controller): 00448086

VBios: Other, BT_1

vbios unlocked

Patching: BT_1 patched.

Read HFS+ file: [hd(0,1)/Extra/modules/uClibcxx.dylib] 77808 bytes.

Module 'uClibcxx.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

 

Do I have to keep all the appleintel kexts?

 

Thanks in advance for your help!

Share this post


Link to post
Share on other sites

Hi all,

I'm trying to use this hack but I got stuck with 1280x720 res.

 

 

Module 'Symbols.dylib' by 'Chameleon' Loaded.

Description: Chameleon symbols for linking

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/klibc.dylib] 44252 bytes.

Module 'klibc.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/Resolution.dylib] 30676 bytes.

Module 'Resolution.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Resolution: 1024x768x32

core proc identified

Detected chipset/proc id (DRAM controller): 00448086

VBios: Other, BT_1

vbios unlocked

Patching: BT_1 patched.

Read HFS+ file: [hd(0,1)/Extra/modules/uClibcxx.dylib] 77808 bytes.

Module 'uClibcxx.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

 

Do I have to keep all the appleintel kexts?

 

Thanks in advance for your help!

Are you using my resolution modules and compiling from scratch, or are you using RemC's module? If you're using mine, try double-checking your DTD. By the looks of the log, the resolution you're telling it to patch is 1024x768. In other words, the Resolution module is reading your DTD and is coming out as 1024x768. And I recall in other threads, you personally have 1280x720 in your VBIOS, but you go up to 1366x768 (like me) in Windows.

 

However, if you're using RemC's modules, I'm not sure what is wrong because I didn't help write it. You'd have to wait to when RemC is online so he can help you.

 

And no, you don't need any of the AppleIntelHD* kexts. Unless you're using Snow Leopard for QE/CI, you don't need them. This is all based on the generic VGA driver that reads VBIOS resolutions.

Share this post


Link to post
Share on other sites

Thanks a lot for the prompt reply iWin32. I was using RemC's module. If I use yours and compile I get this:

 

 

odule 'Symbols.dylib' by 'Chameleon' Loaded.

Description: Chameleon symbols for linking

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/klibc.dylib] 44252 bytes.

Module 'klibc.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/Resolution.dylib] 26568 bytes.

Module 'Resolution.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Parse Edid: edid_checksum error error

Best mode: 1024x768x32

getResolution: 1024x768x32

core proc identified

Detected chipset/proc id (DRAM controller): 00448086

VBios: OtherStarted mode table scan at: 0xC0010

Ended mode table scan at: 0xC0269

Table size: 0x24

, BT_1

vbios unlocked

Addr: 254 Before patch: 0 - after patch: 54

 

Finished Patching at C0000 locking bios.

Best mode: 1024x768x32

Read HFS+ file: [hd(0,1)/Extra/modules/uClibcxx.dylib] 77808 bytes.

Module 'uClibcxx.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

 

My DTD is: 54 1C 56 A0 50 00 16 30 30 20 35 00 58 C1 10 00 00 18

 

I greatly appreciate your help, Thanks

Share this post


Link to post
Share on other sites

Hi Pentothal,

 

I'm trying to come up with a more stable patch.

The bit of code that reads your EDID is coming up with the 1024x768x32.

 

A few questions:

Can you post your full EDID?

What is the resolution you expect?

What hardware are you using?

Share this post


Link to post
Share on other sites

My EDID:

 

00 FF FF FF FF FF FF 00 51 F3 91 50 00 00 00 00 0E 10 01 03 80 22 13 FF 2F 00 00 A0 57 49 9B 26 10 48 4F 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 54 1C 56 A0 50 00 16 30 30 20 35 00 58 C1 10 00 00 18 00 00 00 FC 00 49 6E 74 65 72 6E 61 6C 20 4C 43 44 0A 00 00 00 FD 00 00 3C 00 A2 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49

 

I'm expecting 1366x768. The same resolution I get in W7.

 

I'm using a Toshiba satellite pro s500. I3-350M. No dedicated graphics.

Do you need other specs?

 

Thanks in advance

Share this post


Link to post
Share on other sites

I could see from your DTD that is is indeed 1366x768. I think I know where the problem must be so I've added some debug information to the attached Resolution.dylib.

I also hardcoded the 1366x768x32, so it should also give you full resolution (still does for me)! Please try and paste the bdmesg part from Resolution.dylib that can help me fix it.

 

Others: Don't try this...

Resolution.tar.gz

Share this post


Link to post
Share on other sites

Great, great, great job Indeed! I confirm I have 1366x768x32 resolution now!

I've been waiting for this fix for ages and you RemC made it real! I cannot find the words to thank you!

 

I attach the bdmesg:

 

 

Module 'Symbols.dylib' by 'Chameleon' Loaded.

Description: Chameleon symbols for linking

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/klibc.dylib] 44252 bytes.

Module 'klibc.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/Resolution.dylib] 30676 bytes.

Module 'Resolution.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

edid_checksum failed

Resolution (hardcoded): 1366x768x32

0x448086 core proc 1st gen identified, i=0, devId=02D01

Detected chipset/proc id (DRAM controller): 00448086

VBios: Othermap->mode_table_size=0x24

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x1274

map->mode_table.resolution 0x1274

map->mode_table.resolution 0x1274

r1=310 r2=364 entry_size=38

map->mode_table_size=0x24

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x1274

map->mode_table.resolution 0x1274

map->mode_table.resolution 0x1274

r1=310 r2=364 entry_size=28

map->mode_table_size=0x24

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x136

map->mode_table.resolution 0x16C

map->mode_table.resolution 0x1A2

map->mode_table.resolution 0x1D8

map->mode_table.resolution 0x20E

map->mode_table.resolution 0x244

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x11F2

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x120C

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1226

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x1240

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x125A

map->mode_table.resolution 0x1274

map->mode_table.resolution 0x1274

map->mode_table.resolution 0x1274

r1=310 r2=364 entry_size=8

, BT_1

vbios unlocked

Patching: BT_1 patched.

vbios_resolution_type1 * ptr = 0xc0136

x2=50 x1=56 x_total=90 y2=30 y1=0 y_total=1d

Read HFS+ file: [hd(0,1)/Extra/modules/uClibcxx.dylib] 77808 bytes.

Module 'uClibcxx.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

 

Thanks again brillant job!

Share this post


Link to post
Share on other sites

Great! The EDID checksum failed as I suspected causing it to fall back to a default 1024x768x32 resolution.

Something else to look into :-) I should be able to debug it with the EDID you've provided, cheers.

I'll come up with an improved Resolution.dylib at some point, just familiarizing myself with the code at the moment and then start improving it.

In the meanwhile you've got full resolution!

Share this post


Link to post
Share on other sites

Hi Pentothal,

 

Your EDID checksum is fine. It looks like the code that retrieves your EDID is not working in your case and as a result continues with an empty EDID, which is of course is not working. I've added another Resolution.dylib, I'd appreciate it if you could try it and post me the debug info (should still give you full resolution, but additional verbosity should help me pinpoint the problem).

 

Thanks, RemC

Resolution_1.tar.gz

Share this post


Link to post
Share on other sites

Hi RemC,

I thank you again and confirm your second resolution patch is still giving me 1366x768x32 resolution. Below the debug info:

 

 

Module 'Symbols.dylib' by 'Chameleon' Loaded.

Description: Chameleon symbols for linking

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/klibc.dylib] 44252 bytes.

Module 'klibc.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

Read HFS+ file: [hd(0,1)/Extra/modules/Resolution.dylib] 30676 bytes.

Module 'Resolution.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

getEDID status = 1, EDID:

0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

edid_checksum failed: csum=0x0, all_null=0x0

Resolution (hardcoded): 1366x768x32

0x448086 core proc 1st gen identified, i=0, devId=02D01

Detected chipset/proc id (DRAM controller): 00448086

VBios: Othermap->mode_table_size=0x24

map->mode_table_size=0x24

map->mode_table_size=0x24

, BT_1

vbios unlocked

Patching: BT_1 patched.

vbios_resolution_type1 * ptr = 0xc0136

x2=50 x1=56 x_total=90 y2=30 y1=0 y_total=1d

Read HFS+ file: [hd(0,1)/Extra/modules/uClibcxx.dylib] 77808 bytes.

Module 'uClibcxx.dylib' by 'Unknown' Loaded.

Description:

Version: 0

Compat: 0

 

Cheers

Pentothal

Share this post


Link to post
Share on other sites

Thanks for that! All the zero's confirm that the EDID is not being read. The question now is why? Your systems might not support VBE/DDC, I will have to put some checks in place to determine that and once done ask you one more time (hopefully...) to test something for me. For now could you please answer the following:

 

- When choosing Mac OS X in the bootloader and pressing the arrow down key, a menu pops up...if you choose Video Info, what does the first line say (VBE...?).

- How did you manage to get your EDID?

- You said you're using Win 7, do you have linux as well by any chance or a bootable DVD/USB with Ubuntu or something. If so would you mind running the following and posting the output:

$> sudo apt-get update && sudo apt-get install read-edid

$> sudo get-edid | parse-edid

 

Thanks a lot!

Share this post


Link to post
Share on other sites

No problem at all RemC, I'm more than happy to help you out.

 

- When choosing Mac OS X in the bootloader and pressing the arrow down key, a menu pops up...if you choose Video Info, what does the first line say (VBE...?).

 

I'm booting from a usb pen. No Chameleon installed so no menu. Before booting I ran this command: ?Video. I attach the screenshot of the results.

post-774766-0-25265400-1357861686_thumb.jpg

 

 

- How did you manage to get your EDID

I got it using ELDIM Edid viewer and reading the EDID from w7 registry.

 

 

- You said you're using Win 7, do you have linux as well by any chance or a bootable DVD/USB with Ubuntu or something. If so would you mind running the following and posting the output

 

I ran the commands from Linux Mint 11. Below the output:

 

 

udo get-edid | parse-edid

parse-edid: parse-edid version 2.0.0

get-edid: get-edid version 2.0.0

 

Performing real mode VBE call

Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0

Function supported

Call successful

 

VBE version 300

VBE string at 0x11100 "Intel®Ironlake Mobile Graphics Chipset Accelerated VGA BIOS"

 

VBE/DDC service about to be called

Report DDC capabilities

 

Performing real mode VBE call

Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0

Function supported

Call successful

 

Monitor and video card combination does not support DDC1 transfers

Monitor and video card combination supports DDC2 transfers

0 seconds per 128 byte EDID block transfer

Screen is not blanked during DDC transfer

 

Reading next EDID block

 

VBE/DDC service about to be called

Read EDID

 

Performing real mode VBE call

Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0

Function supported

Call failed

 

The EDID data should not be trusted as the VBE call failed

parse-edid: EDID checksum passed.

 

# EDID version 0 revision 0

Section "Monitor"

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# Block type: 2:0 3:0

Identifier "@@@:0000"

VendorName "@@@"

ModelName "@@@:0000"

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# DPMS capabilities: Active off:no Suspend:no Standby:no

 

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# Block type: 2:0 3:0

# Block type: 2:0 3:0

EndSection

 

I hope my infos are useful for you and the comunity.

Cheers

Pentothal

Share this post


Link to post
Share on other sites

Hi Pentothal,

 

Thanks for all the information, couldn't have asked for more! I'm glad you ran the read-edid utility on Linux because this shows that your monitor and video card combination supports the DDC2 protocol, but somehow fails to execute properly (hardware bug in the implementation of DDC2 in either the monitor or the video card??). It looks like it won't be possible in your case to use the EDID in the Resolution module, so I probably use the values from the "Graphics Mode" in that case.

I'm still not sure how Windows got that EDID in the registry, it might be that the graphics driver has generated it instead of retrieved it from the monitor. At least I now know this is a possible scenario and will try to work around it when I detect it. Thanks for all the testing, I'm busy the next few days but hopefully can start patching things up next week.

 

RemC

Share this post


Link to post
Share on other sites

It kind of sucks that we can't use the AppleIntelHDGraphicsFB kext. I'll give instructions here if anyone wants to try and see what I mean. Its always good to see it yourself.

 

You'll need another computer with a VNC client. If you don't have another one, then don't try it.

 

Basically you will need these kexts:

 

AppleIntelHDGraphicsFB.kext

AppleIntelHDGraphicsGA.plugin

AppleIntelHDGraphicsGLDriver.bundle

AppleIntelHDGraphicsVADriver.bundle

 

If you are gonna try this, your going to have to edit the AppleIntelHDGraphicsFB.kext plist file. The reason is because if your hackintosh fails to boot, you will be able to boot into safe mode. It's a safetly measure.

 

Inside the AppleIntelHDGraphicsFB.kext plist file, scroll down until you see this line of code here:

 

<key>OSBundleRequired</key>
<string>Safe Boot</string>

 

Delete that and save it.

 

Next, go to System Preferences>Sharing and check the option "Screen Sharing".

 

Write down the VNC IP address on a piece of paper or something. It should look like "192.168.1.2" or something similar with different numbers. If you want you can set a VNC password by clicking "Computer Settings".

 

Now we are ready to install the kexts. Install the modified AppleIntelHDGraphicsFB.kext along with AppleIntelHDGraphicsGLDriver, AppleIntelHDGraphicsVADriver, and AppleIntelHDGraphicsGA using Kext Utility or something.

 

Once everything is set up, leave your hackintosh alone.

 

Now login to your other computer and setup a VNC viewer such as TightVNC, UltraVNC, Chicken of the VNC, etc.

 

Once its installed and ready to use, connect to the IP address you wrote down earlier. If successful you will see your hackintosh desktop on your other computer.

 

That's all you need to do. :)

 

Okay, reboot your hackintosh and boot with the "-f" flag (Ignore kernel cache).

You will notice that your screen will turn black, but your backlight is still on. This is the problem you get when you use the AppleIntelHDGraphics framebuffer.

 

Once the screen is black, connect to your hackintosh using a VNC client on another computer. Use the IP address of the hackintosh to connect. Once it connects, you will see the desktop. One strange thing you'll notice is that if you go to System Preferences>Displays, you will see new resolutions as well as the model of the internal display.

 

This basically means that the framebuffer gets all the information of the internal display without any problem. Sadly its useless. :(

Share this post


Link to post
Share on other sites

I don't know much about the AppleIntelHDGraphics kexts (or kexts in general), except for that I have to delete them to make my system work :-) At the moment I'm using natit.kext which at least makes my screensaver work and probably some other stuff. Definitely not hardware accelerated. Natit/Titan are not drivers and only written to enable NVIDIA and ATI cards by manipulating the registry. It seems the project dates from 2006 but no development has been done since? It might be possible to add support for INTEL cards, the fact that my screensaver is working with it indicates that at least something can be achieved! Any thoughts?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Posts

    • Hi I m trying to install High Sierra 10.13.4 in my dell Inspiron N5110 using MBR patch .Please help me with post installation procedures for patching audio graphics etc    specs                                                                     Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz ,                                                                               Display Adapters    NVIDIA GeForce GT 525M  Intel(R) HD 3000 Graphics           IDT  92HD87B1 audio driver  Dell Wireless 1702 802.11 b/g/n, Bluetooth 3.0+HS Driver           USB Controllers  Intel(R) 6 Series/C200 Series Chipset Family USB Enhanced Host Controller - 1C26 Intel(R) 6 Series/C200 Series Chipset Family USB Enhanced Host Controller - 1C2D Bluetooth Hard Copy Cable Replacement Server Renesas Electronics USB 3.0 Host Controller                                                                                                                       
    • Hi there, You can either use Lilu.kext and nVidiaGraphicsFixUp.kext or you can add the following patch to your config.plist under Kernel and Kext Patches: The kexts must be placed under the following path: /EFI/Clover/kexts/Other    Name: com.apple.driver.AppleGraphicsDevicePolicy Find: BA050000 00 Replace: BA000000 00   You can use clover configurator to mount the EFI partition on the drive that you have clover bootloader installed.
    • Hackintosh High SIerra 10.13.3 After installing Nvidia Web Driver System Boot Black Screen. Booting With " nv_disable=1 " Boot Flag System booting Fine But Graphics Was Laggy And 3D Graphics Acceleration Problem. What Can I Do Plz Help ............................. Sorry For My Bad English, English Is Not My Native Language.   My System RIG :   CPU : Intel Core i5 6400 RAM : 8GB HDD : 1TB WD For Windows And 500 GB WD For Hackintosh Graphics Card : Gigabyte GTX 1050Ti 4GB OC Mother Board : Gigabyte H110M-H DVD RW LG
    • grazie icanaro del suggerimento ma avevo già provato..nulla..continua a non andare..allego tutto l'occorrente..   Hack_Info.zip MarioLaptop.ioreg.zip
    • grazie icanaro del suggerimento ma avevo già provato..nulla..continua a non andare..


×