Intel HD Gen 1: Hướng dẫn toàn tập trên Mac OS X

---- phần 5 ----

1. DSDT (Differentiated System Description Table)

Every good hack starts with the DSDT. By hacking the DSDT, you can inject all sorts of information into OS X such as hardware information, fix certain issues, and more. The problem however is that the DSDT is not an easy thing to edit and understand. While it may be possible to fix a lot of OS X problems, it requires a certain amount of knowledge and examination on what every bit of code does. For this guide, I will only focus on hacks that affect the Intel HD Graphics IGPU.

For this section, all the screenshots are from a sample DSDT that I compiled for this guide.

The DSDT screenshots here may look different from yours. Every computer manufacturer has their own style of writing a DSDT.

What this means is that certain DSDT sections may have a different name. For example GFX0 might be named as IGPU instead. They both mean the same thing, just different name. Also, the locations of these sections may be different. With a little bit of exploring, you can find it. Again, same thing but different location.

Take a look at this DSDT:

There is a lot of stuff to see. But its not as bad as it looks once you get comfortable. Let's begin with some simple hacks.

1.1 Find DSDT Integrated Graphics Section

What is this integrated graphics section in the DSDT? This section is where your IGPU properties are located. How do we find this section in the DSDT? We can use IORegistryExplorer to find it. Let's look at a sample IORegistryExplorer screenshot with the IGPU highlighted.

On the left side, you notice that GFX0@2 is highlighted. This is the IGPU. Your computer might have the name different. Sometimes it can be called just IGPU or VID or something similar. Same thing but different name.

On the right side, look at the acpi-path line. This will give us the location of the IGPU in our DSDT. Let's examine the address: "IOACPIPlane:/_SB/PCI0@0/GFX0@20000".

Think of "IOACPIPane:" as "DefinitionBlock "DSDT.aml".



The next part is "/_SB". Think of that as "Scope _SB". However, there is a problem. There are multiple Scope _SB folders. What now?



This is why the IORegistryExplorer address is useful. We know that inside "Scope_SB" there should be "/PCI0@0" section. It turns out that the first "Scope_SB" folder has "/PCI0@0" section. Think of "/PCI0@0" as just "PCI0".



The last thing we need to find is "GFX0@20000". Opening up "PCI0", we can already see GFX0. Think of "GFX0@20000" as just "GFX0" under the 20000 address.



That's it. We found the integrated graphics section. If your still curious about the 20000 address, the red line highlights where that address number comes from.

1.2 DSDT Integrated Graphics Section - Get Rid of Natit Kext

Before continuing, your DSDT needs to be patched with the DTGP method already. All DSDT hacks require this method or you will get compilation errors.

Let's say that your one of the users that has to use the Natit kext in order for you to boot into the desktop. We can do the same thing that Natit does by injecting that information into the DSDT. That way, you will never use that Natit kext anymore!

In order to get rid of Natit, we will need to inject three essential codes. They are called "AAPL,os-info", "VRAM,totalsize", and "model".

Before we do that, we need to prepare the GFX0 (IGPU/VID) section. If you never edited this section, this is how it looks like:

In order for our hacks to work, we need to add the DSM method into this section. This is the DSM method code.

Method (_DSM, 4, NotSerialized)
{
Store (Package ()
{
//Hacks are put in here.//
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}

*You can copy and paste this code into the DSDT if you like to save time.

This code goes under Name (_ADR, 0x00020000) or something similar.



This is how it should look like overall:

Now, we are ready to start. First we need "AAPL,os-info". 1st Generation Intel HD Graphics IGPU has 3 known os-info codes.

30 49 01 11 01 10 08 00 00 01 00 00 00 00 00 00 FF FF FF FF

30 49 00 14 14 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

30 49 01 01 01 00 08 00 00 00 00 00 00 00 00 00 FF FF FF FF

For this guide, the first os-info code is recommended. This is the same code that the original 2010 MacBook Pro (6,1/6,2) uses and it is the default code that the AppleIntelHDGraphicsFB.kext outputs as well. We need to inject this information into the DSDT. This is the format used:

"AAPL,os-info",
Buffer ()
{
0x30, 0x49, 0x01, 0x11, 0x01, 0x10, 0x08, 0x00,
0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF
}

*You can copy and paste this code into the DSDT if you like to save time.

The reason why the os-info numbers need a "0x" prefix is because this tells OS X that these numbers are hexadecimal numbers. Let's put this into the DSDT. This is how it should look like:



It looks right, but there is a problem. We need to add two more codes. The problem that we have here is this bracket here.



If os-info was the final code that we were going to add into the DSM method, then ending the code with "}" is correct. But because we need to tell OS X that there are other codes that needs to be read, we have to add a comma after that bracket. It should be "}," instead. Add a comma after the bracket and this is how it should look like:



Next, we need to add "VRAM,totalsize". This tells OS X how much VRAM the Intel HD Graphics IGPU has. When the Intel HD Graphics IGPU is enabled, it only has a maximum of 288MB of VRAM. You can confirm this number by looking at OpenGL Extensions Viewer.

You can change this code to say 128MB or 512MB or 768MB or whatever number you want. It will display this number in About This Mac and System Information. However the IGPU will always use 288MB so its only cosmetic. This is the code needed:

"VRAM,totalsize",
Buffer ()
{
0x00, 0x00, 0x00, 0x12
}

*You can copy and paste this code into the DSDT if you like to save time.

This code is in hexadecimal format. The code correctly states 288MB. Remember to add a comma after the bracket because we still have one more code to add. This is what you should have so far:



The last thing we need to get rid of Natit kext is to add "model" into the DSDT. This is the "model" code.

"model",
Buffer ()
{
"Intel HD Graphics"
}

*You can copy and paste this code into the DSDT if you like to save time.

This code adds the model name of the IGPU to About This Mac and System Information. Because we are using 1st Generation Intel HD Graphics, Apple calls our IGPU as simply "Intel HD Graphics". Again, you can change this code to anything you want like "Apple Graphics 5000" or "I Love Mac Graphics" but its only cosmetic so there's no benefit.

Because this is the last code, we don't need to add a comma. This tells OS X that all final injected codes stop here. This is what it should look like overall:



That's it! All you need to do now is compile it, save it, configure your bootloader to use it, remove Natit kext and rebuild cache. After that, restart your computer and your desktop should now load without Natit anymore.

Once a DSDT is compiled, the compiler will fill in numbers inside the Buffer() and Package() paranthesis. If you are going to edit these codes again, you have do delete these numbers inside the parenthesis or you will get compilation errors.

1.3 DSDT - Brightness Values for Internal LCD

 Before continuing, your must have already followed mnorthern's guide to enable brightness functionality on your computer. If you have not read his thread, then this will not work.

Remember when you had to add the PNLF section into your DSDT? This method allows OS X to recognize your internal LCD and enable brightness functionality. This is also the place where all your brightness levels are located. Let's take a look at this PNLF section:

*Your DSDT may look different from the one shown here.

If you don't remember where it is, it is suppose to be located just before Scope_PR. In my case, it was located under the Scope_SB folder. The code is a bit longer than what is shown in the screenshot. Here is the full PNLF code that I use for my computer:

Device (PNLF)
  {
   Name (_HID, EisaId ("APP0002"))
   Name (_CID, "backlight")
   Name (_UID, 0x0A)
   Name (_STA, 0x0B)
   Method (_BCL, 0, NotSerialized)
   {
    Return (Package (0x13)
    {
     0x0384,
     0x0384,
     Zero,
     0x012C,
     0x0258,
     0x0384,
     0x04B0,
     0x05DC,
     0x0708,
     0x0834,
     0x0960,
     0x0AC8,
     0x0BB8,
     0x0CE4,
     0x0E10,
     0x0F3C,
     0x10CC,
     0x1194,
     0x12C0
    })
   }
   Method (_BCM, 1, NotSerialized)
   {
    Store (0x80000000, LEVW)
    Store (0x13121312, LEVX)
    Store (0x80000000, LEV2)
    Store (Arg0, LEVL)
   }
   Method (_BQC, 0, NotSerialized)
   {
    Return (BRTL)
   }
   Method (_DOS, 1, NotSerialized)
   {
    ^^PCI0.GFX0._DOS (Arg0)
   }
  }
}

*You cannot copy this code. You must find the values that work for your internal LCD. Continue to read.

For this section, we will be focusing on this part of the code:



And to be more exact, we're going to focus on the BCL method inside the PLNF section:




Let's look at the code piece by piece. This is the first part:

Method (_BCL, 0, NotSerialized)
   {
    Return (Package (0x13)
    {

Method (_BCL, 0, NotSerialized) is a box that holds all of the brightness values. We will open the box with an open bracket "{". To make our lives easier, Return (Package (0x13) tells us how many things there are inside this box in hexadecimal format. For this BCL method, you cannot change this. I will explain why in a bit. Let's continue to look inside the box by using another open bracket "{".

                                 0x0384,
     0x0384,
     Zero,
     0x012C,
     0x0258,
     0x0384,
     0x04B0,
     0x05DC,
     0x0708,
     0x0834,
     0x0960,
     0x0AC8,
     0x0BB8,
     0x0CE4,
     0x0E10,
     0x0F3C,
     0x10CC,
     0x1194,
     0x12C0

What you see here are numbers in hexadecimal format. Look at this diagram:



There are 19 values total but the top 2 values belong to brightness preset values and the other 17 values belong to the brightness slider in OS X. You cannot change the order of these values.

Now the question that you are asking is what do the hexadecimal numbers stand for? Here are the hexadecimal numbers converted to regular numbers:

0x012C means the number 300.
0x0258 means the number 600.
0x0384 means the number 900.
0x04B0 means the number 1200.
0x05DC means the number 1500.
0x0708 means the number 1800.
0x0834 means the number 2100.
0x0960 means the number 2400.
0x0AC8 means the number 2700.
0x0BB8 means the number 3000.
0x0CE4 means the number 3300.
0x0E10 means the number 3600.
0x0F3C means the number 3900.
0x010CC means the number 4200.
0x01194 means the number 4500.
0x012C0 means the number 4800.

 Remember, the brightness values must be converted to hexadecimal format or they will not work. That is how OS X reads them.

Now that you know what the numbers stand for, lets look at first part. These are the brightness preset values.

                                 0x0384,
     0x0384,

Now the order of these two codes are important. The top part switches the brightness level to 900 when the computer boots up with AC is connected or when you connect the AC to charge the battery. The bottom part switches the brightness level to 900 when the computer boots up using battery or when you disconnect the AC.

 0x0384, (Brightness value when AC is connected)
 0x0384, (Brightness value when Battery is being used)

Now lets look at the second part. These are the 17 brightness levels.

                                 Zero,
     0x012C,
     0x0258,
     0x0384,
     0x04B0,
     0x05DC,
     0x0708,
     0x0834,
     0x0960,
     0x0AC8,
     0x0BB8,
     0x0CE4,
     0x0E10,
     0x0F3C,
     0x10CC,
     0x1194,
     0x12C0

The order is common sense. The lowest brightness value is 0 (Zero). The highest brightness value is 4800 (0x12C0).

 The values for the brightness preset values must be from the 17 brightness levels.

To make things easier to read:

1. Zero, (Lowest Level - Zero means black screen)
2. 0x012C,
3. 0x0258,
4. 0x0384,
5. 0x04B0,
6. 0x05DC,
7. 0x0708,
8. 0x0834,
9. 0x0960,
10. 0x0AC8,
11. 0x0BB8,
12. 0x0CE4,
13. 0x0E10,
14. 0x0F3C,
15. 0x10CC,
16. 0x1194,
17. 0x12C0 (Highest Level)

The reason why there are 17 levels of brightness is because that is the maximum amount of levels that the slider can change to. If there are less or too much than 17, it will not work. You must come up with 17 values. You can repeat values if you want as long as there are 17.

Under construction...

1. I have Intel HD Graphics on my computer. Will this guide work for me?

This guide was written specifically for users that have a 2010 Intel Core i Series processor (Core i3, Core i5, Core i7) with Intel HD Graphics or a 2010 Intel Pentium processor with Intel HD Graphics. They are part of the Arrandale CPU family (mobile processors).

Device ID: 0042 or 0046
Vendor ID: 8086

If you have a Sandy Bridge or Ivy Bridge processor, it is not supported here.

2. Why should I enable Core Image? Why should I enable Quartz Extreme?

If you run OS X without Core Image and/or Quartz Extreme, then it will be a slow experience and the Intel HD Graphics IGPU will not be put to good use. Even if your internal LCD is using the eDP connector, it is important to enable Core Image as it will make the Intel HD Graphics IGPU partially work and give you partial acceleration.

3. I installed the Intel HD Graphics QE/CI kexts. When I boot, the spinning wheel stops spinning. Why?

The problem here is that you most likely chose the wrong framebuffer. On some computers, you only need the regular framebuffer. On other computers however you need to use the Alternate or Alternate 2 framebuffers. If you run into trouble, boot into Safe Mode and delete the framebuffer. Then install another framebuffer.

4. I installed the Intel HD Graphics QE/CI kexts. When I boot, the spinning wheel spins forever. Why?

This usually happens when the framebuffer fails to inject the os-info automatically. To prevent this, install Natit.kext or inject this information into your DSDT. Another reason might be is that you need to use an Alternate or Alternate 2 framebuffer.

5. I installed the Intel HD Graphics QE/CI kexts. When I boot, the internal display turns off, or there is only a black screen with backlight, or white screen. Why?

If your internal LCD is using the eDP connector, this will happen. Currently, there is no fix for eDP users at this time. However, if your internal LCD is using the LVDS connection, then your display may need a DualLink framebuffer. If you use a SingleLink framebuffer for a DualLink display, it will stay black because the display needs dual transmission signals. Another reason would be is that you did not patch the framebuffer correctly. Remember, if the internal display's native resolution is higher than 1366x768, you must install a DualLink framebuffer.

6. QE/CI is working but in About This Mac and System Information, it says Graphics Unknown and 64 MB. Why?

This happens when OS X fails to get the proper information for the Intel HD Graphics IGPU. This should not affect the performance because this information is only cosmetic. You can either fix this by installing Natit.kext or you inject this information into your DSDT.

7. I connected a VGA display or HDMI display into the port. Why aren't they working?

This is a known problem. This problem is related to the framebuffer. Currently, HDMI is not supported. If you want to use an external VGA display, follow the instructions in the Display Ports section but you will have to disable your internal LCD display. You cannot have both VGA and internal LCD working which means you cannot extend display and you cannot mirror displays.

8. What SMBIOS should I use?

The recommended SMBIOS to use is either MacBookPro 6,1 or MacBookPro 6,2. You can generate an SMBIOS with Chameleon Wizard or Champlist.

9. Ever since I enabled QE/CI, my computer is heating up. Why?

Now that the Intel HD Graphics IGPU is working, it will make your computer temperature rise slightly but this is normal. However, if you currently don't have native power management working, then your computer will overheat and turn off. Read #5 in Extras (Optional) section to enable power management. An alternative would be to create a custom SSDT.

10. Sometimes my computer makes this chirping or weird sound when using the Intel HD Graphics IGPU. Why?

It has nothing to do with the IGPU. This sound comes from your internal speakers. Caused by VoodooHDA or AppleHDA kexts.

11. The Intel HD Graphics IGPU lags sometimes. Why?

There can be many reasons to this. It is important to note that the Intel HD Graphics IGPU will never be as fast as a dedicated graphics card. Second, updating to the latest version of OS X might resolve some of your issues. Third, if you are using a distro and not a vanilla install, that can cause performance issues. Fourth, it might be because your processor has a low clock speed which also affects the Intel HD Graphics IGPU.

12. Does the Intel HD Graphics IGPU work on OS X 10.9 Mavericks?

Yes.

All credit goes to the members mentioned in this post.

Guide Version History:

2.7
*Added Display Ports section. Contains information about using an external VGA display.

2.8
*Added official OS X Mavericks 10.9 CI and QE/CI packages links.

 If this guide has helped you, be sure to press the "Like" button! 

• Tweet
• Share
• Share
• Share
• Share

Sign up here with your email