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

[gygabyte666]

And can you post ioreg (please use IORegistryExplorer v2.1). Thanks!

Here you go. 17t-j000_ioreg_05032014.zip

 

Sorry for the wait but my schedule is kind of strange and I can't always get things done when i'd like to.

 

Anyway, included is 2 ioreg dumps. The first, is just a simple dump of the system running with the current/latest config.plist, that should be the one you are after. The second dump is exactly the same except I enabled Clover's FixRegions flag before dumping it. Might not be useful to you but I figured what the hell.

[RehabMan]

Here you go. 17t-j000_ioreg_05032014.zip

 

Sorry for the wait but my schedule is kind of strange and I can't always get things done when i'd like to.

 

Anyway, included is 2 ioreg dumps. The first, is just a simple dump of the system running with the current/latest config.plist, that should be the one you are after. The second dump is exactly the same except I enabled Clover's FixRegions flag before dumping it. Might not be useful to you but I figured what the hell.

I don't think FixRegions is configured correctly in config.plist. No sign of the logs that would result.

 

I think it has something to do with your DSDT fixes being specified "old way" From bootlog:

34:474  0:000  Apply DsdtFixMask=0x10000000 old way
34:474  0:000     drop _DSM mask=0xFFFF

Use Clover Configurator to do it. I would suggest you re-create your config.plist because Clover Configurator cannot load it (there must be an error in it).

 

FYI: PNLF is coming from patch to SSDT in ioreg (first ssdt that clover would load, you may be calling it SSDT-1.aml). The PNLF patch is my "Brightness Fix (Haswell)". The files you sent in the current/edits directory at one point do not have this patch. At least that mystery is solved, as I didn't think it was possible to have backlight control with the files you originally sent. Like I said, ioreg always reflects reality.

[gygabyte666]

I don't think FixRegions is configured correctly in config.plist. No sign of the logs that would result.

 

I think it has something to do with your DSDT fixes being specified "old way" From bootlog:

 

34:474  0:000  Apply DsdtFixMask=0x10000000 old way
34:474  0:000     drop _DSM mask=0xFFFF

Use Clover Configurator to do it. I would suggest you re-create your config.plist because Clover Configurator cannot load it (there must be an error in it).

 

FYI: PNLF is coming from patch to SSDT in ioreg (first ssdt that clover would load, you may be calling it SSDT-1.aml). The PNLF patch is my "Brightness Fix (Haswell)". The files you sent in the current/edits directory at one point do not have this patch. At least that mystery is solved, as I didn't think it was possible to have backlight control with the files you originally sent. Like I said, ioreg always reflects reality.

Hmm, alright. It's very likely since I never updated the config. Been using the same one for awhile now. I actually wasn't sure how to update it without a clean wipe/reinstall. Is Clover Configurator the pref pane or is it an app I can download? I'd prefer to avoid any more pref panes if possible.

 

I knew PNLF was in my SSDT-1 so that's no surprising. I know BC I put it there, I just didn't think that alone would make AppleBacklight actually work but it does. I have a separate SSDT for ACPIBacklight PNLF testing, although it needs updating.

[RehabMan]

Hmm, alright. It's very likely since I never updated the config. Been using the same one for awhile now. I actually wasn't sure how to update it without a clean wipe/reinstall. Is Clover Configurator the pref pane or is it an app I can download? I'd prefer to avoid any more pref panes if possible.

CC is an app.

 

I knew PNLF was in my SSDT-1 so that's no surprising. I know BC I put it there, I just didn't think that alone would make AppleBacklight actually work but it does. I have a separate SSDT for ACPIBacklight PNLF testing, although it needs updating.

It is surprising because in post #414, I asked for your native files and the current patched files you were using. In post #415 you provided them. But the patched SSDT-1 in post #415 does not contain PNLF.

 

When later I asked for Clover F4 dump, we discovered that the native files provided in post #415 did not reflect the current native ACPI tables.

When later I asked for ioreg, we discovered that the patched files contain SSDT-1.aml with PNLF.

 

If I have some time, I can work on my automated repo to work (or determine what tweaks are necessary) with your native files. I would need a native dump from Linux, just because the scripts are written to work with the names as formed in /sys/firmware/acpi/tables. I plan to integrate the keyboard patches anyway, as I can plainly see they apply to my original DSDT on the J063cl as well.

[gygabyte666]

CC is an app.

OK, cool. Thanks.

 

It is surprising because in post #414, I asked for your native files and the current patched files you were using. In post #415 you provided them. But the patched SSDT-1 in post #415 does not contain PNLF.

 

When later I asked for Clover F4 dump, we discovered that the native files provided in post #415 did not reflect the current native ACPI tables.

When later I asked for ioreg, we discovered that the patched files contain SSDT-1.aml with PNLF.

 

If I have some time, I can work on my automated repo to work (or determine what tweaks are necessary) with your native files. I would need a native dump from Linux, just because the scripts are written to work with the names as formed in /sys/firmware/acpi/tables. I plan to integrate the keyboard patches anyway, as I can plainly see they apply to my original DSDT on the J063cl as well.

Really? I was under the impression I was using an SSDT with PNLF in it. Hmm. I really though that PNLF was included in my current files. Strange. I guess remaking the config.plist is a very wise idea since something is certainly screwy.

 

OK, well I'll try to get a little time and put together some new dumps from Linux. Let me know if you'd like them.

[RehabMan]

OK, cool. Thanks.

 

Really? I was under the impression I was using an SSDT with PNLF in it. Hmm. I really though that PNLF was included in my current files. Strange. I guess remaking the config.plist is a very wise idea since something is certainly screwy.

You are *using* an SSDT with PNLF in it, as shown in ioreg extraction of said SSDT. But things were confusing there since the files you *sent* were not the ones you were actually using.

 

Confusion results from this:

me: Can you send me your files

you: here they are

me: Interesting, there is no PNLF in here... Are your brightness controls working?

you: Brightness is working since I injected EDID

me, thinking: EDID does not impact brightness adjustment.. no PNLF... no brightness controls. WTF? Maybe Clover option for PNLF...

me: Can you send me your config.plist/ioreg?

you: here it is

me, looking at config.plist/ioreg: No PNLF option in config.plist, but... Look, PNLF is defined in SSDT-1.

 

Conclusion #1: files sent originally did not reflect reality.

 

Conclusion #2: always ask for ioreg, to keep head scratching to a minimum!

 

Hope that clears it up :-)

 

OK, well I'll try to get a little time and put together some new dumps from Linux. Let me know if you'd like them.

Definitely...

 

I'll try to make my repo as flexible as I can given the two sets (my original set, and yours).

[gygabyte666]

You are *using* an SSDT with PNLF in it, as shown in ioreg extraction of said SSDT. But things were confusing there since the files you *sent* were not the ones you were actually using.

 

Confusion results from this:

me: Can you send me your files

you: here they are

me: Interesting, there is no PNLF in here... Are your brightness controls working?

you: Brightness is working since I injected EDID

me, thinking: EDID does not impact brightness adjustment.. no PNLF... no brightness controls. WTF? Maybe Clover option for PNLF...

me: Can you send me your config.plist/ioreg?

you: here it is

me, looking at config.plist/ioreg: No PNLF option in config.plist, but... Look, PNLF is defined in SSDT-1.

 

Conclusion #1: files sent originally did not reflect reality.

 

Conclusion #2: always ask for ioreg, to keep head scratching to a minimum!

 

Hope that clears it up :-)

 

 

Definitely...

 

I'll try to make my repo as flexible as I can given the two sets (my original set, and yours).

Well, WTH then? Perhaps I'm using an SSDT that has an extra patch in it, one that escaped my usual cloud upload. I'll compare it to the one I sent you and if it is indeed different then I apologize , and I'll upload the correct one. Usually I don't change things so I really thought the one I sent you was the same as what's in my clover setup. The dsdt and ssdt-2 should be the right ones though.

 

I misunderstood what you were saying before, I thought you were telling me that my PNLF inject was coming from somewhere *other* than from my ssdt-1. Confusion cleared up. >_

[RehabMan]

Well, WTH then? Perhaps I'm using an SSDT that has an extra patch in it, one that escaped my usual cloud upload. I'll compare it to the one I sent you and if it is indeed different then I apologize , and I'll upload the correct one. Usually I don't change things so I really thought the one I sent you was the same as what's in my clover setup. The dsdt and ssdt-2 should be the right ones though.

Best to go right to /EFI/Clover/ACPI/patched and grab the ones there.

 

Resolved now, so no big deal, but had me scratching my head... because I always assume that when I say "send me the files you're using" that people will go to the actual directory where the bootloader loads them from... not some backup location which may or may not be the same bits.

 

I misunderstood what you were saying before, I thought you were telling me that my PNLF inject was coming from somewhere *other* than from my ssdt-1. Confusion cleared up. >_

I did at one point think it might come from config.plist as you:

- sent me a set of patched files with no PNLF

- claimed that backlight controls were working

- concluded that it has to be config.plist PNLF option as it can't come from anywhere else...

 

Glad we have that bit of confusion cleared up.

 

Bottom line: I'm certain ACPIBacklight.kext will work once DSDT/SSDTs are re-patched from current native tables.

[gygabyte666]

Best to go right to /EFI/Clover/ACPI/patched and grab the ones there.

 

Resolved now, so no big deal, but had me scratching my head... because I always assume that when I say "send me the files you're using" that people will go to the actual directory where the bootloader loads them from... not some backup location which may or may not be the same bits.

Understandable but as I mentioned, I keep all of my working edits backed up and don't make frequent changes so in most cases, grabbing them from the backup location or from the original clover directory shouldn't make a difference. Unfortunately, in this case that proved to have different results. Oh well...

 

I did at one point think it might come from config.plist as you:

- sent me a set of patched files with no PNLF

- claimed that backlight controls were working

- concluded that it has to be config.plist PNLF option as it can't come from anywhere else...

 

Glad we have that bit of confusion cleared up.

 

Bottom line: I'm certain ACPIBacklight.kext will work once DSDT/SSDTs are re-patched from current native tables.

Agreed. Glad it's all semi-worked out. I'll repatch them and post the results after testing.

[gygabyte666]

So, I spent some time and remade my dsdt/ssdts. I made a little text document with all the patches I used for later reference and hopefully it'll make future patching a bit quicker and easier. Sadly though, and after all of it, i'm finding that it did not solve my issues with ACPIBacklight. Did I miss a step? I applied your repo fix "Brightness fix (Haswell)" to my SSDT-1 (since this is where GFX0/IGPU is), copied SSDT-1 to Clover's EFI partition, installed ACPIBacklight, repaired perms, rebuilt kernel/kextcaches and rebooted. ACPIBacklight loads for PNLF and brightness slider exists and functions but it doesn't change my brightness levels. I'm still stuck at max. For the record, and to make sure my setup was as close to the original as possible I ran without ACPIBacklight first and AppleBacklight worked fine as it did before. The only issue i'm facing is ACPIBacklight still not working.

 

Humor me for a second. Technically speaking, using Clover's F4 dump option would result in creating the same files as a clean Linux dump right? I used the files generated from Clover's F4 dump as my new files. Hopefully they are the same as what would have come from a Linux dump, otherwise i'll be doing this again soon.

 

Oh and I remade my config.plist using Clover Configurator as you suggested, RehabMan. Great suggestion BTW! I didn't know it existed.

[RehabMan]

So, I spent some time and remade my dsdt/ssdts. I made a little text document with all the patches I used for later reference and hopefully it'll make future patching a bit quicker and easier. Sadly though, and after all of it, i'm finding that it did not solve my issues with ACPIBacklight. Did I miss a step? I applied your repo fix "Brightness fix (Haswell)" to my SSDT-1 (since this is where GFX0/IGPU is), copied SSDT-1 to Clover's EFI partition, installed ACPIBacklight, repaired perms, rebuilt kernel/kextcaches and rebooted. ACPIBacklight loads for PNLF and brightness slider exists and functions but it doesn't change my brightness levels. I'm still stuck at max. For the record, and to make sure my setup was as close to the original as possible I ran without ACPIBacklight first and AppleBacklight worked fine as it did before. The only issue i'm facing is ACPIBacklight still not working.

Upload the following:

- Clover F4 dump

- ioreg

- config.plist

- output of 'kextstat|grep -y acpiback' in Terminal

 

Humor me for a second. Technically speaking, using Clover's F4 dump option would result in creating the same files as a clean Linux dump right? I used the files generated from Clover's F4 dump as my new files. Hopefully they are the same as what would have come from a Linux dump, otherwise i'll be doing this again soon.

It creates the same files, but with different names.

[gygabyte666]

Upload the following:

- Clover F4 dump

- ioreg

- config.plist

- output of 'kextstat|grep -y acpiback' in Terminal

17t_j000_ACPIBacklight_issues.zip

114    0 0xffffff7f829c2000 0x3000     0x3000     com.darwin.driver.ACPIBacklight (2.0.2) <77 10 4 3>

It creates the same files, but with different names.

Ok, that's good. Thanks!

[RehabMan]

17t_j000_ACPIBacklight_issues.zip

114    0 0xffffff7f829c2000 0x3000     0x3000     com.darwin.driver.ACPIBacklight (2.0.2) <77 10 4 3>

Ok, that's good. Thanks!

 

Try without Clover config.plist based patches for Azul. Make sure vanilla Azul is on disk.

[gygabyte666]

Try without Clover config.plist based patches for Azul. Make sure vanilla Azul is on disk.

Done. My Azul is vanilla, no edits are directly performed on it. The only changes made to it are done through Clover's kext patching. No change unfortunately. I ran a few tests, once without my config.plist Azul FB patch and one without the FB patch and without my EDID injection. Neither made any difference, ACPIBacklight still doesn't work with my machine. Bummer.

 

Could my GeForce be causing this? I know your test machine didn't have a GeForce in it so this is the only explanation that I could come up with.

[RehabMan]

Done. My Azul is vanilla, no edits are directly performed on it. The only changes made to it are done through Clover's kext patching. No change unfortunately. I ran a few tests, once without my config.plist Azul FB patch and one without the FB patch and without my EDID injection. Neither made any difference, ACPIBacklight still doesn't work with my machine. Bummer.

 

Could my GeForce be causing this? I know your test machine didn't have a GeForce in it so this is the only explanation that I could come up with.

Make sure you rebuild cache after restoring vanilla Azul to disk (otherwise patched version can still be in kernel cache).

 

Not sure. Others with nvidia (optimus) have used it with success.

 

I think something is wrong with your ACPI patching process, but can't put my finger on it. There are definitely some unnecessary patches in your files. When I get some time, I may try to run it through my patching process...

 

Oh, one other thing... Just to verify something, install debug version of ACPIBacklight.kext and provide ioreg.

When I get some time, I may try to run it through my patching process...

Here is something to try. Add ig-platform-id=0xa260006 to Clover config.plist, add Inject/Intel=true. Place these files in ACPI/patched. Add your CPU SSDT-1.aml. Should have DSDT.aml, SSDT-4.aml (from this archive), and your CPU SSDT-1.aml only.

 

These files do not have the EC/keyboard patches, but otherwise are pretty close to yours. Try then, post ioreg.

Archive.zip

[gygabyte666]

Make sure you rebuild cache after restoring vanilla Azul to disk (otherwise patched version can still be in kernel cache).

 

Not sure. Others with nvidia (optimus) have used it with success.

 

I think something is wrong with your ACPI patching process, but can't put my finger on it. There are definitely some unnecessary patches in your files. When I get some time, I may try to run it through my patching process...

 

Oh, one other thing... Just to verify something, install debug version of ACPIBacklight.kext and provide ioreg.

I always boot without caches during a change like this. I rebuild caches and then reboot into normal boot, so the caches aren't an issue.

 

Here is this: 17t_j000_05092014_ACPIBacklight_Debug.ioreg.zip

 

Here is something to try. Add ig-platform-id=0xa260006 to Clover config.plist, add Inject/Intel=true. Place these files in ACPI/patched. Add your CPU SSDT-1.aml. Should have DSDT.aml, SSDT-4.aml (from this archive), and your CPU SSDT-1.aml only.

 

These files do not have the EC/keyboard patches, but otherwise are pretty close to yours. Try then, post ioreg.

Ok, the archive you sent includes a dsdt and ssdt-4. Obviously, the dsdt makes sense but i'm confused on what i'm supposed to add to this. The included ssdt-4 seems to be a replacement to my current ssdt-1. When you say "CPU SSDT-1" I assume you mean my ssdt-2 since that's the only ssdt I use for CPU-support. So, am I supposed to use the included dsdt, rename the included ssdt-4 to ssdt-1 (to mirror my setup) and include my own CPU ssdt-2 and retest using ACPIBacklight debug? Is this correct?

 

UPDATE: Not sure if what I mentioned above is what you were trying to get me to do but I did it anyway and have the results. ACPIBacklight doesn't work still but here's the ioreg you requested from that test: 17t_j000_05092014_dsdt_ssdt1_swap.ioreg.zip

[warlikewings]

Did you ever have a chance to try "use system I/O" "drop OEM" "inject intel" and "inject EDID"? Those are the settings in my config that allowed me (when using your dsdt and ssdt 1/ssdt 2) to use the stock OS X backlight kext. In theory that should be all it would take for you. With these options and your dsdt/ssdt files I had acpi backlight working fine, and there's nothing else I can think of that had to do with it.

[gygabyte666]

Did you ever have a chance to try "use system I/O" "drop OEM" "inject intel" and "inject EDID"? Those are the settings in my config that allowed me (when using your dsdt and ssdt 1/ssdt 2) to use the stock OS X backlight kext. In theory that should be all it would take for you. With these options and your dsdt/ssdt files I had acpi backlight working fine, and there's nothing else I can think of that had to do with it.

AppleBacklight works fine with my machine. We are trying to get ACPIBacklight working with my machine.

[RehabMan]

I always boot without caches during a change like this. I rebuild caches and then reboot into normal boot, so the caches aren't an issue.

 

Here is this: 17t_j000_05092014_ACPIBacklight_Debug.ioreg.zip

Thanks, I just wanted to verify that the PNLF was coming from _SB.PNLF and had the correct BCL.

 

Ok, the archive you sent includes a dsdt and ssdt-4. Obviously, the dsdt makes sense but i'm confused on what i'm supposed to add to this. The included ssdt-4 seems to be a replacement to my current ssdt-1. When you say "CPU SSDT-1" I assume you mean my ssdt-2 since that's the only ssdt I use for CPU-support. So, am I supposed to use the included dsdt, rename the included ssdt-4 to ssdt-1 (to mirror my setup) and include my own CPU ssdt-2 and retest using ACPIBacklight debug? Is this correct?

Clover does not care if the SSDTs are not sequential. Your SSDT-7 (patched) comes out of my script as SSDT-4 (script is based on Linux dump, Linux dump SSDT4 is the one with GFX0 definition). Clover will load SSDT.aml, and SSDT-?.aml (where ? is a digit), no matter if there are gaps or not. I tend to keep my names as they were (eg. SSDT4 from Linux, patched -> SSDT-4.aml) to create less confusion. Generally, I name generated CPU SSDT (from ssdtPRgen.sh) to SSDT.aml)

 

UPDATE: Not sure if what I mentioned above is what you were trying to get me to do but I did it anyway and have the results. ACPIBacklight doesn't work still but here's the ioreg you requested from that test: 17t_j000_05092014_dsdt_ssdt1_swap.ioreg.zip

OK, couple of ideas...

 

- Let's make certain the files you provide as origin are current... (Linux dump to compare)

- Maybe Linux provides different than Clover F4?

- Maybe you need SSDT-8 (nvidia SSDT, would need to be patched for IGPU rename) for correct ACPI initialization?

 

Also, it might be worthwhile disabling nvidia from SSDT. It is probably something you should do anyway(battery life).

[Demonbane]

Hi Rehabman,

 

i have disabled my nvdia graphic card by modifying the dsdt, (add the _OFF method into INI). it seems to be successful, but even so, i can still feel the heat from the bottom of my laptop near the graphic card part. but under windows, it's totally cool.

 

is there any other way to disable the graphic card by editing the dsdt more perfectly? (i know i could flash a modified bios, but my laptop is not able to do that...)

 

Thanks in advance

 

 

 

++++ here is my current DSDT.dsl  DSDT.dsl.zip

[RehabMan]

Hi Rehabman,

 

i have disabled my nvdia graphic card by modifying the dsdt, (add the _OFF method into INI). it seems to be successful, but even so, i can still feel the heat from the bottom of my laptop near the graphic card part. but under windows, it's totally cool.

 

is there any other way to disable the graphic card by editing the dsdt more perfectly? (i know i could flash a modified bios, but my laptop is not able to do that...)

 

Thanks in advance

 

 

 

++++ here is my current DSDT.dsl  DSDT.dsl.zip

Not really sure. For most, _OFF works. I don't have any such hardware (have no need for discrete graphics).

[Demonbane]

Hi Rehabman, Why didn't the Rename GFX0 to IGPU patch work for me?

 

no patches no changes...

 

plz have a look at it acpi_dsdt.dsl.zip

[RehabMan]

Hi Rehabman, Why didn't the Rename GFX0 to IGPU patch work for me?

 

no patches no changes...

 

plz have a look at it acpi_dsdt.dsl.zip

Don't know. Something in your DSDT is confusing MaciASL.

[warlikewings]

Has anyone attempted to get OS X 10.10 developer preview running on their Envy yet? I've been trying, but it looks like the locked msr issue applies here too, and the mach_kernel has been moved somewhere else.

[gygabyte666]

Has anyone attempted to get OS X 10.10 developer preview running on their Envy yet? I've been trying, but it looks like the locked msr issue applies here too, and the mach_kernel has been moved somewhere else.

I don't have an ability to test 10.10 yet but are you sure the mach_kernel was moved and the installer isn't just relying on kernelcaches in place of it?

 

UPDATE: see post #453