Contribute
Register

[FIX] HD4200/HD4400/HD4600/HD5600 on 10.11+

Sierra lag freeze on Safari is COMPLETELY SOLVED! Beautiful people from applelife.ru create a binary patch for AppleIntelHD5000Graphics via AppleALC (it's more completely and stable method) and we have a good news for all - founded a better solution. Via AppleALC method video not laggy after sleep, and power returns at normal values (via old patch for AppleIntelHD5000Graphics CPU power in vatts up to 300-400%, via AppleALC method it's working normally).

Instructions:
1) DISABLE ALL patches in config.plist for AppleIntelHD5000Graphics/AppleIntelFramebufferAzul
2) Copy AppleALC.kext to kexts/10.12 (download it from this post)
3) Reboot
4) ???
5) Profit!!!

Better regards from Russia!
 

Attachments

  • AppleALC.kext.zip
    518.1 KB · Views: 130
Sierra lag freeze on Safari is COMPLETELY SOLVED! Beautiful people from applelife.ru create a binary patch for AppleIntelHD5000Graphics via AppleALC (it's more completely and stable method) and we have a good news for all - founded a better solution. Via AppleALC method video not laggy after sleep, and power returns at normal values (via old patch for AppleIntelHD5000Graphics CPU power in vatts up to 300-400%, via AppleALC method it's working normally).

Instructions:
1) DISABLE ALL patches in config.plist for AppleIntelHD5000Graphics/AppleIntelFramebufferAzul
2) Copy AppleALC.kext to kexts/10.12 (download it from this post)
3) Reboot
4) ???
5) Profit!!!

Better regards from Russia!

I don't see any commit in the AppleALC github related to AppleIntelHD5000Graphics patching.
 
This patch not be a official commited. Vit9696 use own AppleALC as the patcher of disassembled code of AppleIntelHD5000Graphics, because AppleALC can do it better than Clover, which functions it is a binary patches only.

Here is link from original thread:
https://applelife.ru/threads/shiki-patcher-polzovatelskogo-urovnja.1349123/page-22#post-637442

Thanks for the link.

My take...

It all looks pretty sketchy... talk of serious efficiency/battery issues too.
And unfortunately requires use of AppleALC for your audio solution.
 
Thanks for the link.

My take...

It all looks pretty sketchy... talk of serious efficiency/battery issues too.
And unfortunately requires use of AppleALC for your audio solution.
1) Battery issues fixed few days ago. My Apple ALC's is fixed to CPU power (code updated with other user in .ru thread, look to next page).

2) May be.. Hmm... Fork AppleALC and remove all code, which the inject audio? AppleALC - it's a simply kext patcher, adapted to Audio Inject. Therefore, it's may be a universal solution to such look patches.

Vit9696 doesn't plan to continue this work. AppleALC method isn't really convenient, but a fully worked. Therefore as it seems to me, it is difficult to look for better decision - Clover, for example, won't be able to make it.
 
Yes... both string and data work. But string has no error checking and not sure if it handles spaces as you showed in your text. Hence the suggestion to use data.

By "space" I assume you're referring to this:
Code:
31C04889 8568FFFFFFE9A4F9FFFF
        ^

Surely the space is not supposed to be there?

I have been using the patch for a while without it and it appears to work.
Code:
 - [11]: AppleIntelHD5000Graphics (Fix video playback freeze) :: BinPatch :: [OS: 10.12.3 | MatchOS: All | MatchBuild: All] ==> allowed
Does this mean the patch was successful?

I just tried to modify this patch in Clover Configurator and set the Type/Key to DATA. It wont allow you to use the DATA format unless you specify it as an "InfoPlistPatch". I have no idea what that means.
 
Last edited:
By "space" I assume you're referring to this:
Code:
31C04889 8568FFFFFFE9A4F9FFFF
        ^

Surely the space is not supposed to be there?

Clover might ignore the space (I have not looked at the code in a while... if you're curious, examine the relevant Clover source code). But best to use 'data' instead of 'string'.

I have been using the patch for a while without it and it appears to work.

Then it implies Clover ignores the space.

Code:
 - [11]: AppleIntelHD5000Graphics (Fix video playback freeze) :: BinPatch :: [OS: 10.12.3 | MatchOS: All | MatchBuild: All] ==> allowed
Does this mean the patch was successful?

It means only that the specified MatchOS matches the version about to be booted.

I just tried to modify this patch in Clover Configurator and set the Type/Key to DATA. It wont allow you to use the DATA format unless you specify it as an "InfoPlistPatch". I have no idea what that means.

Don't use Clover Configurator.
 
Clover might ignore the space

Since the original patch is a series of hex bytes I would assume a space would be 0x20 and not a literal space.

It means only that the specified MatchOS matches the version about to be booted.

Is there any log I can check to see if a kext patch has succeeded or failed? There is the possibility I have not crashed out of luck or something else.

Don't use Clover Configurator.

I can't find an example of how to create a patch using the hex byte version instead of Base64. Do you have to specify the format somehow or does Clover automatically detect it?
 
Since the original patch is a series of hex bytes I would assume a space would be 0x20 and not a literal space.

I believe Clover ignores the space (0x20 is not a valid hex digit).
I don't know what you mean by 0x20 vs. "literal space". Space is ASCII 0x20.

Is there any log I can check to see if a kext patch has succeeded or failed? There is the possibility I have not crashed out of luck or something else.

You can try with and without the patch to verify behavior. If the bug fixed by the patch is present without the patch, but not present with the patch, then you know the patch is applied successfully.

Or you could specify the patch as data, as suggested earlier.

I can't find an example of how to create a patch using the hex byte version instead of Base64. Do you have to specify the format somehow or does Clover automatically detect it?

Use a plist editor. Hex will automatically be converted to base64.
 
I believe Clover ignores the space (0x20 is not a valid hex digit).
I don't know what you mean by 0x20 vs. "literal space". Space is ASCII 0x20.

I'm just saying if the author of the original patch wanted an actual space in the hex data it would be a hex value of 0x20 (I just use the 0x prefix to denote hex) and not a literal ASCII char (' '). I don't know why he's put a space in there but I don't think it's supposed to be a part of the patch.

Just to be sure I've opened up the AppleIntelHD5000Graphics kext in a hex editor and did a search.

k5ldSwL.png


So I think we can now say for sure the space is not part of the patch. So it's quite safe to convert these hex bytes to base64 and just ignore the space.

Use a plist editor. Hex will automatically be converted to base64.

The online hex to base64 converter is also quite good. It will also strip out any spaces in the hex data. I use TextWrangler to edit config.plist so I'm probably unusual in that sense.

PS Thanks for all the work you do for this community.
 
Last edited:
Back
Top