AppleIntelSKLGraphicsFramebuffer.kext mods…

I presume that most people are using the following frame buffer data:

0000 1219 0103 0303 0000 0004 0000 2002
0000 5001 0000 0060 6C05 0000 6C05 0000
0000 0000 0000 0000 FF00 0000 0100 0000
4000 0000 0105 0900 0004 0000 0705 0000
0204 0A00 0004 0000 0705 0000 0306 0A00
0004 0000 0705 0000 0601 0000 0000 0800
0200 0000 0400 0000 80DF 1710 0000 0000
7805 0000 D205 0000 4006 0000 0000 0000
0000 0000 0000 0000

Or a slightly modified one, but I use this (was like the one above)

0300 1219 0001 0101 0000 0002 0000 3001
0000 0000 0000 0060 9914 0000 9914 0000
0000 0000 0000 0000 FF00 0800 0002 0000
4000 0000 FF05 0000 0100 0000 4000 0000
FF04 0000 0100 0000 4000 0000 FF00 0000
0100 0000 4000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000

Note that pretty much every value was changed, including the framebuffer ID, the total number of frame buffers, planes and ports – changed to one. Everything done on purpose. To show you that it can be done, and that the red values are kind of special. Well. For now that is. But please note that I inject this data, but you may not need all changed values. Again, I did this to figure out what we can change, and what not (the red values).

Let’s start with the value 40 You can change this into 30 to get an internel panel. Which is what notebook users want. Also. I cannot change 05 into anything else, without breaking my HDMI monitor – the display turns black. Same thing with 04 because whatever value I use there, then the DVI monitor turns black.

I have no idea why, but it almost looks like Apple/Intel is either using a wrong frame buffer index value – the green bytes – or they are not checking the frame buffer index value at all. I mean my HDMI and DVI monitor are always connected to the first frame buffer, and that is probably also why we can only use one monitor at a time. This also includes remote desktop usage and that sucks, so hopefully this will be fixed soon/tomorrow – or whenever Apple releases (the next) 10.11.3 (DP).

Perhaps this is the workaround that notebook users are looking for, or perhaps they need to swap/change the value (05 and 04). Just give it a try and let me know if this works for you. Thanks.

Note: The Gigabyte B150M-D3H (DDR3) motherboard that we used – thanks Jens – for testing uses port 6 for the DVI and port 5 for the HDMI monitor. By the way. His Geekbench 3 results can be found here and this is the speed of his Samsung SM951 SSD (AHCI).
Samsung SM951 AHCI
Pretty amazing for the Intel i7-6700 (non K) processor.

p.s. Nope. Sorry. The frame buffer edits will not magically “fix” the screen garbage.

23 thoughts on “AppleIntelSKLGraphicsFramebuffer.kext mods…

  1. Hey Pikeralpha, now my skylake laptop runs (no wifi/poor 7MB HD530) what must i do to test your mod? i opened the AppleIntelSKLGraphicsFramebuffer Binary with HexFriend but i cant find any value from your post

    • Look for: 00 00 12 19 in the binary, and skip to the second match (that is the framebuffer data you are going to change) and inject the new data, and the ID 0x19120003 (that is what I am using) with either Clover or Chameleon.

      • No. I only used the frame buffer data of 0x1912000 because it was the only frame buffer data that worked for me, without QE/CI, and you should not inject the AAPL,platform-id property with a value of 0x19120000 because then it will not enable QE/CI. That is why I use 0x1912003, but you can change this value to anything but 0x1912000.

      • ok so if i am getting this right. Your real device id is 19120003 and you are using framebuffer from 19120000 to make it work. Funny is that i can use any id but i am still getting unable to load driver error message. Maybe i should try to mess around a bit and try different FB’s.

      • No. The device id is 0x1912 for the desktop configuration that I use for testing, and I inject the AAPL,device-id property with a value of 0x19120003, to make it work on the desktop (because Apple checks for 0x19120000) which is basically nothing more than a modified version of the original 0x19120000.

        If your device-id is not 0x1912 then you should not have to worry about the Apple check in the binary, but then you’ll have to use my data with the exception of the frame buffer ID aka the first four bytes.

        One question; What is your device id?

  2. My ID is 0x191b. It is a mobile version of HD530.

    What i can see in framebuffer file is that the only 191b device which have a framebuffer data is 0x191b0000 (mine default id is 0x191b0006). If i use this ID 0x191b0000 as fakeID the error message “can’t load framebuffer” is gone but i still don’t have qeci. If i replace the hex 00001b19 with 06001b19 (which should theoretically do the same as faking ID) the error is still there.

    • You mean Clover injects 0x191b0006 instead of 0x191b0000?

      The value of your AAPL,ig-platform-id property should point to frame buffer data that can be used/matches with your hardware!

      There is no 0x191b0006 in the kext that I have here. Was that added in a later revision/update of the kext? I’m confused. Where is that 0x191b0006 coming from?

      Also. Have you checked: /var/log/displaypolicyd.log

      • ok correction. I was on wrong track how it works. FakeID needs to be 0x19XX8086 for intel and then as you said i just need to use ig-platform-id “compatible” with my hardware. So when i was injecting wrong fakeid 0x191b0000 the vendor was “0000” so no intel > thats why i did not get the IGPU error. It was not even trying to load any framebuffer. But as i mentioned earlier the only framebuffer data available so far is 191b0000. So my only possible combination is fakeid 0x191b8086 (which i don’t have to use becuase its detected correctly even when i left it empty) and the ig-device-id set to 0x191b0000. But somehow i still get the framebuffer load failed error message.

        In the displaypolicyd.log i can only see the repeating message “AGDC support not present on system. Policy engine instance init failed”

        PS: sorry for confusion.

      • Like I said. The injected AAPL,ig-platform-id should point to frame buffer data that works. You just pick one. It doesn’t have to be compatible with the hardware, but right now there are only a few frame buffers that can/should work without too much efforts.

        And we already figured out that Apple checks for ID 0x19120000 – which may change any time soon – so your best change of getting it to work is to:

        1.) Inject AAPL,ig-platform-id 0x191b0000 without fakeid.
        2.) Inject AAPL,ig-platform-id 0x19120001 with fakeid.

        In both cases you will have to mod the frame buffer data. And just to be certain that we are on one line: You really need to modify the frame buffer data (seriously) for option 2!

        We also know – thanks to darkvoid for figuring it out after the Haswell processors where first released – that there may be one or more bundles/plugins/libraries that also need to be patched, but you first have to get that frame buffer working. And as soon as it boots properly, then please let me know where your display shows up in IORegistryExplorer.

        For now. Always boot in single-user (-s) mode so that you can restore the frame buffer binary when it doesn’t work. Also, Give it some time when your display stays black (may take a while).

        Tip: If your notebook has external display connectors, like HDMI/DP/DVI then always check if that works.

      • Thanks man for the explanation. I am really noob in these things. I will certainly try your advice also with the hdmi connector. Only thing that bothers me is. I know that the framebuffer does not have to work with my hardware. But should i at least not get the “can’t load framebuffer” error message? Should not the framebuffer load anyways even if its wrong? I mean if i got black screen that’s good because i know that i am getting somewhere and it gets loaded but its just not working. But any ID, any combination i try i always get that it can’t be loaded. For an example. If there are data for 191b0000 and my device is 191b and i use the platform-id 0x191b0000 this should load the framebuffer right? There should not be a message that it can’t be loaded. Also if i change the fakeid to 0x19128086 and use platform-id 0x19120001, then also using clover replace the hex from 00001219 to 01001219 (the second match as you mentioned) also should not the framebuffer get loaded?

        Thanks for your patience with me 😀 I really appreciate that.

      • No worries. We all had to start at some point. Just keep attacking it and don’t give up. One of these days you will experience that… ‘oh my lord’ moment 😉

        Now. You will get the: “can’t load framebuffer” error when something is wrong with the frame buffer data. Which is a good starting point, as it shows you that the kexts is trying to use the data. It’s just not right.

        The factory original frame buffer data with ID 0x19120001 will disable the IGPU (activates kiosk mode) so you have to patch it. The easiest way is to copy the entire frame buffer with ID 0x19120000 over it, and then slowly patch it. Step by step. Start with the ID (of course).

        And again about the black screen. It may take some time to get to the desktop. I know. Been there myself.

  3. Hello Pike,
    Today I tried installing El Capitan onto one of my friend’s laptop that has an i5-6200U and Intel HD Graphics 520. When I got into the installer, I don’t see any screen garble at all ( tried like 4 times ), but when booting into a working OS X ( with QE/CI fully enabled ), it glitches so badly. Was the problem lies in the AppleIntelSklGraphics.kext ( the installer doesn’t have that one ) or was it the AppleIntelSklGraphicsFramebuffer.kext ? Given the info.plist doesn’t have anything strange, I can’t figure out the answer to this problem

  4. Hello,
    I am trying to get the LVDS display to work on my Asus H110 motherboard with HD530 from I7 CPU. I found these informations from a post somewhere :
    Framebuffer@0 to port 7 with connector type which is DVI.
    Framebuffer@1 to port 5 with connector type which is HDMI.
    Framebuffer@2 to port 6 with connector type which is HDMI.
    Framebuffer@3 to port 7 with connector type which is DisplayLink
    Do you know what is the connector type for LVDS?

  5. “HDMI and DVI monitor are always connected to the first frame buffer, and that is probably also why we can only use one monitor at a time.”

    Hi @pikeralpha. Any further progress or breakthroughs since your original blog post? On Sierra 10.12.3 now. Some time / months later. Yet so far, the best thing I have found to date is this guide: by @wildwillow. It works around and trys to avoid the matter by hot-plugging 2nd monitor after login. Unfortunately for users like me, who have a ‘cheaper’ motherboard like mentioned here in your post, the ‘Gigabyte B150M-D3H’. (several similar models with DSUB, DVI, HDMI). Then the hot-plug solution just doesnt really work very well for us and remains quite far from ideal. My details are posted over on @wildwillow’s thread so will not repeat them again here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s