HP Envy 17t-j000 Quad (Haswell) + 10.8.5/10.9.5/10.10.x/10.11.x/10.12.x/10.13.x/10.14.x

[RehabMan]

So, the new ENVY's dsdt is a disaster. It simply doesn't seem to extract well. I have included the dsdt for examination in the hopes of finding some help with it. It's a broken mess.

 

I managed to mostly clean up the required ssdts already (i hope) but without a functional dsdt, I can't really accurately test them and this dsdt has so many problems that I just don't know what else to do to try to fix it anymore. Unlike the 17t this one even references TONS of data from the other ssdts, which to me makes absolutely no sense and kind of defeats the point of having separated tables.

 

I'm hoping someone else had/has a machine like this one that they managed to get sorted out. I already attempted fixing it for days using my old 17t dsdt as a reference but this thing is just so busted it didn't seem to matter much.

 

Any help I can get on this from other, more experienced members would be GREATLY appreciated! I am currently using a modified dsdt from the 17t to even get this thing booting and functioning semi-reasonably. Thanks everyone.

I have a patch repo for Envy Q. It uses Clover hotpatch (no manual patching involved). Read at the linked guide for details on usage.

 

https://github.com/RehabMan/HP-Envy-Q-DSDT-Patch

[gygabyte666]

Hey thanks gygabite666, I am looking into this right now. Good luck with your rig, I like it

 

No problem, I have that same card in 3 different machines and it works very well. I assume it is one of the cards that Rehabman was suggesting you to look into. Thank you and good luck to you as well.

I have a patch repo for Envy Q. It uses Clover hotpatch (no manual patching involved). Read at the linked guide for details on usage.

 

https://github.com/RehabMan/HP-Envy-Q-DSDT-Patch

Hey thanks Rehabman but I may have finally figured it out on my own. I'll know for sure a bit later when I can actually test it but I think I tricked it into playing nice with me finally. Man, that thing had a TON of errors.

 

Oh and while I was hunting I did come across that repo. I smirked when I found it since it meant that you had enough people requesting help with that series that you just made another repo for it, lol. If nothing else, i'll def have to take a look at your battery patch for it since I remember with my old 17t getting that fixed seemed like quite the migraine for you i'm sure, major props again for getting that sorted out.

 

Just for future reference though (and i'm sure you've explained this a bazillion times by now so apologizes) but what do you suggest would be the easiest and simplest way of dumping/patching using your repo? I remember attempting it once but it didn't go very well. As I recall the only reason I needed to do it was to disable optimus, which I will have to do again at some point for this machine too. Thank you again for all your help both now and in the past!

[RehabMan]

Hey thanks Rehabman but I may have finally figured it out on my own. I'll know for sure a bit later when I can actually test it but I think I tricked it into playing nice with me finally. Man, that thing had a TON of errors.

You should really look at the hotpatch setup. It is simply a better technique...

 

Note: If you provide a Clover F4 dump (ACPI/origin). I'll check it against the repo to see if it is a match. Make sure you have the latest BIOS.

 

But your problems with "errors" in the DSDT, are most likely due to incorrect disassembly.

 

Oh and while I was hunting I did come across that repo. I smirked when I found it since it meant that you had enough people requesting help with that series that you just made another repo for it, lol.

It was similar enough to J and K series that it was not difficult to create...

 

If nothing else, i'll def have to take a look at your battery patch

The original patch for battery was already in my laptop repo, but the code now uses hotpatch and an additional SSDT (with patched methods that resulted from the battery patch).

 

Just for future reference though (and i'm sure you've explained this a bazillion times by now so apologizes) but what do you suggest would be the easiest and simplest way of dumping/patching using your repo?

When using hotpatch, there is no ACPI dumping involved. You simply use the config.plist and the SSDT-HACK.aml. All patching is done on-the-fly between Clover and the SSDT.

 

I remember attempting it once but it didn't go very well. As I recall the only reason I needed to do it was to disable optimus, which I will have to do again at some point for this machine too. Thank you again for all your help both now and in the past!

The patch repo has code that automatically disables the Nvidia GPU (if enabled in BIOS).

[gygabyte666]

Note: If you provide a Clover F4 dump (ACPI/origin). I'll check it against the repo to see if it is a match. Make sure you have the latest BIOS.

Of course! I am thankful for the assistance and hopefully these can be helpful to your repo. I included dumps from both the stock BIOS which I believe was revision F.33 and for the most recent update, F.33 Rev.A. It's worth mentioning that I removed MSDM from both dumps for obvious reasons. 

 

Anyway, I hope they prove useful in some way. I'll let the thread know how my (hopefully) fixed dsdt works out once I test it out. Thanks again!

Envy15-q667nr_acpi_dump.zip

[RehabMan]

Of course! I am thankful for the assistance and hopefully these can be helpful to your repo. I included dumps from both the stock BIOS which I believe was revision F.33 and for the most recent update, F.33 Rev.A. It's worth mentioning that I removed MSDM from both dumps for obvious reasons. 

 

Anyway, I hope they prove useful in some way. I'll let the thread know how my (hopefully) fixed dsdt works out once I test it out. Thanks again!

It is very similar to the other Envy-Qs I've run into... But requires slight tweaks.

 

Is it Haswell?

 

I made the tweaks: https://github.com/RehabMan/HP-Envy-Q-DSDT-Patch/commit/268fdba77ce484e02ab96aadb6adba5c24b991ef

You can try it (assuming the laptop is Haswell) and report back...

 

Note: You should check that the audio is still ALC290 like the other Envy-Qs.

[mnfesq]

I looked up the card online, does it come as a replacement for the WIFI one already present?

And while we're in the upgrading process, can I also exchange the HDD with an SDD? It's an Envy j-101sf

 

From what I read, HP doesn't advertise it but it appears that you can use an mSATA SSD as a boot drive or you can use an SSD SATA drive.  I have an older HP Envy and I use the mSATA drive as my boot drive.  In fact, as soon as you plug in the mSATA drive, it automatically becomes the boot drive and you cannot boot from the SATA drive. (In my case, the SATA drive in HD bay 1 since I have a 17-inch Envy with 2 HD bays.)

[OtechMan]

From what I read, HP doesn't advertise it but it appears that you can use an mSATA SSD as a boot drive or you can use an SSD SATA drive.  I have an older HP Envy and I use the mSATA drive as my boot drive.  In fact, as soon as you plug in the mSATA drive, it automatically becomes the boot drive and you cannot boot from the SATA drive. (In my case, the SATA drive in HD bay 1 since I have a 17-inch Envy with 2 HD bays.)

That's awesome, thanks for the heads up. These days I have been wanting to perfect my envy so I ordered the card and then when opening it up I found the mSata spot and thought that it would be great if I buy an mSATA Samsung 850 EVO 500g and install it and leave the HDD for data

[mnfesq]

Of course! I am thankful for the assistance and hopefully these can be helpful to your repo. I included dumps from both the stock BIOS which I believe was revision F.33 and for the most recent update, F.33 Rev.A. It's worth mentioning that I removed MSDM from both dumps for obvious reasons. 

 

Anyway, I hope they prove useful in some way. I'll let the thread know how my (hopefully) fixed dsdt works out once I test it out. Thanks again!

 

I appreciate the fact that you are old-school enough to want to generate a good working DSDT rather than auto-patch and/or patch on the fly with Clover.  Old habits are hard to die and sometimes shouldn't be allowed to die.

That's awesome, thanks for the heads up. These days I have been wanting to perfect my envy so I ordered the card and then when opening it up I found the mSata spot and thought that it would be great if I buy an mSATA Samsung 850 EVO 500g and install it and leave the HDD for data

 

Be sure to read up on how to delete the downloads, movies and music folders from your user directory and create shortcuts to put those folders on your data drive.  That will keep you from filling up your SSD.

[RehabMan]

I appreciate the fact that you are old-school enough to want to generate a good working DSDT rather than auto-patch and/or patch on the fly with Clover.  Old habits are hard to die and sometimes shouldn't be allowed to die.

Sometimes new habits are better than old habits. In that case, old habits should be traded in for new habits.

 

Keep in mind that correctly patching ACPI using Clover hotpatching and SSDTs requires a much greater understanding of ACPI than does patching based on disassembly/patch/recompile. I know only a few that truly understand what's going on... But once a hotpatch setup is created for a given ACPI set (eg. a certain computer model), since it is essentially just a matter of copying files, it is easier to apply by others.

[gygabyte666]

Damn, dsdt is still broken. My fixes got me further than before but it wasn't fixed enough. I still have to use the old 17t to get it to boot. I am def interested in trying other methods now since this seems like it isn't going anywhere.

It is very similar to the other Envy-Qs I've run into... But requires slight tweaks.

Is it Haswell?

I made the tweaks: https://github.com/RehabMan/HP-Envy-Q-DSDT-Patch/commit/268fdba77ce484e02ab96aadb6adba5c24b991ef
You can try it (assuming the laptop is Haswell) and report back...

Note: You should check that the audio is still ALC290 like the other Envy-Qs.

Yes, it's Haswell and yes the audio is ALC290.

How exactly would I go about testing this again?

 

I appreciate the fact that you are old-school enough to want to generate a good working DSDT rather than auto-patch and/or patch on the fly with Clover.  Old habits are hard to die and sometimes shouldn't be allowed to die.

Sometimes new habits are better than old habits. In that case, old habits should be traded in for new habits.

Keep in mind that correctly patching ACPI using Clover hotpatching and SSDTs requires a much greater understanding of ACPI than does patching based on disassembly/patch/recompile. I know only a few that truly understand what's going on... But once a hotpatch setup is created for a given ACPI set (eg. a certain computer model), since it is essentially just a matter of copying files, it is easier to apply by others.

Heh, it's really nothing like that. It's just, this is the only method that I know to use and it served me well in the past, even if it is tedious and sometimes, a pain in the ass. This is the first that i've heard of this "hotpatching" thing and I don't even know how to go about trying it out. I'm just using the methods that I'm familiar with. Jeez, how long was I gone for? >.<

[RehabMan]

Damn, dsdt is still broken. My fixes got me further than before but it wasn't fixed enough. I still have to use the old 17t to get it to boot. I am def interested in trying other methods now since this seems like it isn't going anywhere.

Yes, it's Haswell and yes the audio is ALC290.

How exactly would I go about testing this again?

The guide is linked from the github repo. It is very detailed/precise.

 

Heh, it's really nothing like that. It's just, this is the only method that I know to use and it served me well in the past, even if it is tedious and sometimes, a pain in the ass. This is the first that i've heard of this "hotpatching" thing and I don't even know how to go about trying it out. I'm just using the methods that I'm familiar with. Jeez, how long was I gone for? >.<

The hotpatch term (for this case) is my making... There have been others to use Clover binpatches + SSDTs (TimeWalker, perhaps others), but my techniques a bit different and somewhat easier to put together. The concept is this: instead of disassemble/patch/recompile, patch the native ACPI binaries with Clover, and add SSDTs as needed.

In most cases the SSDTs work in conjunction with the Clover binpatches. My SSDTs are "smart" in that they detect the device-ids and inject properties as appropriate. For example, automatically injecting a fake device-id in the case of HD4200/HD4400/mobile HD4600, but not for Iris graphics or HD5000.

 

Creating a hotpatch set is a bit difficult as you must understand AML binaries, and have a good understanding of ACPI. But using a set already created is not difficult as it is just using the config.plist as written, and copying the hotpatch/add-on SSDTs to ACPI/patched. In the case of my repo, I've automated most of the process. Those that are curious can easily read the scripts, read the config.plist contents, and read the SSDT source.

 

Eventually, I'll write a guide for hotpatch, assuming I can figure a way to explain it well...

 

I created my first hotpatch for the Gigabyte Haswell BRIX. Since the ACPI patches required were really simple (as is the case with most desktops), I decided to try an all Clover Fixes+binpatch + SSDT approach. It wasn't difficult. Next, as a challenge, I did the same with my Lenovo u430. It was a lot more difficult and it took me an entire day (a long one). But I learned a lot along the way. After that, I did it with my desktop, then my two Probooks, then the Lenovo Y50, then the Envy K,Q,and J (other people testing as I don't have these machines). I have a script that can "sanity check" a native ACPI set when the patches + SSDTs are applied without actually running/testing them through Clover. It can catch problems before you actually using the setup live. I already ran it against your files and that's how I discovered the few differences... Along the way, I also helped a few other keen individuals do the same thing...

 

No guarantees that my tweaks are adequate for yours, but I think they are close. Surprised about the changes required, but hotpatching is dependent on BIOS version (more than text based/static patching) as we are patching the actual binary AMLs that BIOS provides. But it has been a while since a new Envy-Q owner has asked me anything, so it is possible a new BIOS made some changes that broke my patches.

 

At any rate, it is worth a try...

[gygabyte666]

The guide is linked from the github repo. It is very detailed/precise.

 

 

The hotpatch term (for this case) is my making... There have been others to use Clover binpatches + SSDTs (TimeWalker, perhaps others), but my techniques a bit different and somewhat easier to put together. The concept is this: instead of disassemble/patch/recompile, patch the native ACPI binaries with Clover, and add SSDTs as needed.

In most cases the SSDTs work in conjunction with the Clover binpatches. My SSDTs are "smart" in that they detect the device-ids and inject properties as appropriate. For example, automatically injecting a fake device-id in the case of HD4200/HD4400/mobile HD4600, but not for Iris graphics or HD5000.

 

Creating a hotpatch set is a bit difficult as you must understand AML binaries, and have a good understanding of ACPI. But using a set already created is not difficult as it is just using the config.plist as written, and copying the hotpatch/add-on SSDTs to ACPI/patched. In the case of my repo, I've automated most of the process. Those that are curious can easily read the scripts, read the config.plist contents, and read the SSDT source.

 

Eventually, I'll write a guide for hotpatch, assuming I can figure a way to explain it well...

 

I created my first hotpatch for the Gigabyte Haswell BRIX. Since the ACPI patches required were really simple (as is the case with most desktops), I decided to try an all Clover Fixes+binpatch + SSDT approach. It wasn't difficult. Next, as a challenge, I did the same with my Lenovo u430. It was a lot more difficult and it took me an entire day (a long one). But I learned a lot along the way. After that, I did it with my desktop, then my two Probooks, then the Lenovo Y50, then the Envy K,Q,and J (other people testing as I don't have these machines). I have a script that can "sanity check" a native ACPI set when the patches + SSDTs are applied without actually running/testing them through Clover. It can catch problems before you actually using the setup live. I already ran it against your files and that's how I discovered the few differences... Along the way, I also helped a few other keen individuals do the same thing...

 

No guarantees that my tweaks are adequate for yours, but I think they are close. Surprised about the changes required, but hotpatching is dependent on BIOS version (more than text based/static patching) as we are patching the actual binary AMLs that BIOS provides. But it has been a while since a new Envy-Q owner has asked me anything, so it is possible a new BIOS made some changes that broke my patches.

 

At any rate, it is worth a try...

Hmm, seems like this could be quite challenging. I have no other leads to help fix my current dsdt issues, aside from injecting code from it into my working 17t dsdt so as far as i'm concerned, your way at least sounds more promising. Besides, it's like you said, it's worth a try. Unfortuantely, I'll be very busy over the next few days so I don't know how much time i'll be able to put into it but i'll do as much as I can and we'll see what comes of it. Thank you for the info.

[OtechMan]

Hmm, seems like this could be quite challenging. I have no other leads to help fix my current dsdt issues, aside from injecting code from it into my working 17t dsdt so as far as i'm concerned, your way at least sounds more promising. Besides, it's like you said, it's worth a try. Unfortuantely, I'll be very busy over the next few days so I don't know how much time i'll be able to put into it but i'll do as much as I can and we'll see what comes of it. Thank you for the info.

gygabite666 you really wanna try this, it takes 15min max, and boy that is change from all the editing you gotta do

[RehabMan]

Hmm, seems like this could be quite challenging. I have no other leads to help fix my current dsdt issues, aside from injecting code from it into my working 17t dsdt so as far as i'm concerned, your way at least sounds more promising. Besides, it's like you said, it's worth a try. Unfortuantely, I'll be very busy over the next few days so I don't know how much time i'll be able to put into it but i'll do as much as I can and we'll see what comes of it. Thank you for the info.

Not challenging if what I've already done works...

 

When it works, it is probably the quickest OS X setup (from nothing to fully working) that you'll ever do.

[gygabyte666]

gygabite666 you really wanna try this, it takes 15min max, and boy that is change from all the editing you gotta do

Not challenging if what I've already done works...

 

When it works, it is probably the quickest OS X setup (from nothing to fully working) that you'll ever do.

Oh, lol I was under the impression I had to do all this dumping/compiling etc but using a different, and unfamilar method. Now i'm really looking forward to giving this a try! I wish I had the time to do this right now but as soon as I do, you'll be the first to know.

[mnfesq]

Sometimes new habits are better than old habits. In that case, old habits should be traded in for new habits.

 

Keep in mind that correctly patching ACPI using Clover hotpatching and SSDTs requires a much greater understanding of ACPI than does patching based on disassembly/patch/recompile. I know only a few that truly understand what's going on... But once a hotpatch setup is created for a given ACPI set (eg. a certain computer model), since it is essentially just a matter of copying files, it is easier to apply by others.

 

I have nothing but respect for the work you've done for the OSx86 community.  My point is that, unless the hot patching method is readily understood by a significant segment of the community, it's better (for the community, maybe not technologically) to use methods that don't require nearly all of the community to rely upon one or two developers to do all the work.  I've used some of your patches for my DSDT and have done many more by using Google.  Once upon a time, Mald0n was one of the only people here that could edit DSDT's.  It's a good thing, in my opinion, when lots of people can edit DSDT's.  Keep working on the hot patch method and don't worry about the community.  We'll catch up to where you are now eventually.  Until then, the more people that understand how to manipulate their DSDT to make their installation work without error, the better.

[RehabMan]

Keep working on the hot patch method and don't worry about the community.  We'll catch up to where you are now eventually.

I will eventually write a guide that explains it, along with some common patches and examples... (some patches and SSDT content are quite generic).

[gygabyte666]

The hotpatch term (for this case) is my making... There have been others to use Clover binpatches + SSDTs (TimeWalker, perhaps others), but my techniques a bit different and somewhat easier to put together. The concept is this: instead of disassemble/patch/recompile, patch the native ACPI binaries with Clover, and add SSDTs as needed.

Rehabman, you sir are truly something else! I managed to sneak in a little free time to try out your hotpatch and it worked! That isn't, to say everything works of course but the majority of things are working and are working about as well as they would have if I had managed to fix the dsdt for this system beforehand. I haven't yet plugged in the battery for this machine to see if the battery detection and capacity measurements are accurate but I will let you know when I do. Very little in terms of testing have been done so far since I have a severe lack of free time in order to do so. So, I am unsure of the system stability and haven't completely weeded out what works vs what doesn't but here is what I do know so far. I'll only list known problem devices, others things work too but aren't relevent to document here. It's probably worth mentioning that this was all tested on 10.9.5 since I love my Mavericks so much!

 

The Good:

Keyboard/touchpad work as well as expected.

Function keys on the keyboard seem to function properly.

Brightness keys display proper icons, as do volume keys. I haven't tested any other keys yet.

I am unsure of the gestures available for the trackpad but I managed to open the finder by swiping 3 fingers up and all other trackpad functions are working well.

Intel HD 4600 support is excellent!

Backlight is responsive and keyboard brightness keys adjust levels properly, even the lowest level acts as a Mac should and disables the backlight entirely.

Happy side note: brightness volumes are saved and restored upon each boot, which is just awesome. Saves me the trouble of having to readjust levels.

Bluetooth on my AW-CE123H is active. Icon showing and is probably working fine. Haven't tested yet.

Wireless card for my AW-CE123H is working and connects normally to networks.

Sleep works well and deep sleep seems to be functioning properly.

USB 3.0 only system has functioning ports and works well thus far. Speed testing on ports untested.

 

The Bad:

No audio right now.

I rebuilt the AppleHDA kext and rebuilt caches but the system hasn't attached yet. Maybe more reboots are still needed.

5GHz wifi doesn't seem to be working for my AW-CE123H yet.

USB devices do NOT wake machine from sleep. USB mouse was used to test with

HDMI untested, without working audio support it seemed unnecessary to test at the moment.

 

Off the top of my head, that's the extent of my testing for the moment. I will poke around with it later to see if I can remedy any of the issues it currently has but compared to the problems it had before, I think it's safe to say that significant progress was made today thanks to your hard work on your hotpatch setup. It's worth noting that it took me a bit longer to get working properly since there were options in the config.plist that didn't agree with my current setup so I have to fix that before Clover would even let me back into OS X again. Long story short, there was an option in the plist that made booting into OS X impossible. It was essentially blocking the Clover driver responsible for showing any and all bootable OS X partitions. Good thing I keep recovery methods around or that could have been pretty bad.

 

Since i'm a sucker for completeness and documenting progress, In your opinion if I were to say, make a dsdt dump with this hotpatch method active, would it dump a nice, "fixed" version that I could use to finish prepping one for this system or would it be too modified to be of much use for such a task? This of course, is nothing but a backup for me in the event somewhere down the line this hotpatch method fails me on this machine and I have to revert to the "old" ways again as a means of booting the OS. Well, that and just to satisfy my awful OCD to keep backups in case I need them.

 

Anyway, I have to wrap this up now. I just wanted to let the thread and you know that I did get around to testing this out. As I mentioned, i'll do more with it later but for now, I have to go to bed. Thank you very much for putting in all the hard work to help make my little success story possible. It really is quite a feat you've accomplished with that repo of yours and I can absolutely see this hotpatch method of yours being used as an alternative means of simplifing OS X installs/setups if it gets to a point where it becomes easily adaptable to a broader range of hardware. If anyone could pull something like that off, my faith rests in you to be the man to do it. Thank you very much for everything that you do and for what you've done.

[RehabMan]

The Bad:

No audio right now.

I rebuilt the AppleHDA kext and rebuilt caches but the system hasn't attached yet. Maybe more reboots are still needed.

AppleHDA itself is not patched on disk. Only AppleHDA_ALC290.kext is installed. AppleHDA itself is patched via Clover. The AppleHDA_ALC290.kext must be regenerated for Mavericks as the one in the repo is for 10.11.3 only. And the procedures for rebuilding cache as documented in "Known Problems" "Audio" (boot without caches, rebuild cache, reboot) are required.

 

5GHz wifi doesn't seem to be working for my AW-CE123H yet.

Fixing the kernel cache should fix it (see above about audio), provided the config.plist is correct.

 

USB devices do NOT wake machine from sleep. USB mouse was used to test with

By design. Wake via USB is disabled to avoid "instant wake".

 

Long story short, there was an option in the plist that made booting into OS X impossible. It was essentially blocking the Clover driver responsible for showing any and all bootable OS X partitions. Good thing I keep recovery methods around or that could have been pretty bad.

It means you forgot HFSPlus.efi (must follow the guide carefully).

 

Since i'm a sucker for completeness and documenting progress, In your opinion if I were to say, make a dsdt dump with this hotpatch method active, would it dump a nice, "fixed" version that I could use to finish prepping one for this system or would it be too modified to be of much use for such a task?

That would defeat the purpose of hotpatch... But yes, you can extract the patched tables with 'patchmatic -extract'. (patchmatic -extract is also an valuable diagnostic tool).

 

Anyway, I have to wrap this up now. I just wanted to let the thread and you know that I did get around to testing this out.

Thanks for testing... nice to know the few tweaks I implemented based on your files... worked out (I'm sure it will help the next person that comes along...)

[gygabyte666]

No audio right now.

I rebuilt the AppleHDA kext and rebuilt caches but the system hasn't attached yet. Maybe more reboots are still needed.

5GHz wifi doesn't seem to be working for my AW-CE123H yet.

USB devices do NOT wake machine from sleep. USB mouse was used to test with

HDMI untested, without working audio support it seemed unnecessary to test at the moment.

All of this is now fixed. Silly me, I just needed to update Clover to the newest version and that solved pretty much everything. Audio works fine now. The 5GHz wifi patch being used was incorrect for Mavericks and I needed to revert to an older one to get it working. Now it works great! HDMI tested and works great for both video & audio. Now I just need to get a working touchscreen driver and I should be all set with this laptop, which is just wonderful!

 

So once more, thank you Rehabman for all your hard work into this. I think I might have to try to update my 17t to use this method too, since it is very easy to setup and works much better than the old methods do. Too bad you don't have a repo for my desktop too. It's ok though, I'll just try to make a hotpatch for that one on my own. Can't have you doing everything now can we?

 

Thanks again!

[OtechMan]

Hey RehabMan, 

 

I casually check sometimes your repositories for updates and saw some changes recently, on the USBEnvy kext as well as the ENVY repo, should I update or am I good now?

 

Thanks as always

[RehabMan]

Hey RehabMan, 

 

I casually check sometimes your repositories for updates and saw some changes recently, on the USBEnvy kext as well as the ENVY repo, should I update or am I good now?

 

Thanks as always

You can read the commit log to decide if the changes interest you...

[gygabyte666]

Anyone have a fix for audio popping?

[RehabMan]

Anyone have a fix for audio popping?

On what hardware? In what conditions?

[Andrw0380]

New requirements for AppleHDA injectors (new entries in Info.plist/OSBundleLibraries). My patch_hda.sh script automatically does the right thing.

 

See here: https://github.com/RehabMan/HP-Envy-DSDT-Patch

Sorry for taking long to respond. I ran your script but it comes up an error " Creating AppleHDA injector for 76e0...cp: invalid option -- 'X'" afterwards most of the output is "No such file or directory". Is there a specific codec I put after ./patch_hda.sh as mine is 111d(vendor IDT) 76e0 (device id) and no matter which combination I put in comes up the same cp error.  

 

As I mentioned before I am on 10.11.4 beta with the j070ca series laptop and the latest beta still doesn't fix Audio. My config.plist hasn't changed for AppleHDA patches that worked in previous El Capitan and AppleHDA is present in /System/Library/Extensions with the "AppleHDA_IDT76e0_Envy.kext" that was in the Envy folder before in /Library/Extensions per your ./install_downloads.sh script. The AppleHDA currently in System/Library/Extensions is version 274.7.

 

BTW the audio popping happens on the IDT 76e0 also when I had audio previously. For my experiment with VoodooHDA, the popping never happened.