Jump to content

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
 Share

1,321 posts in this topic

Recommended Posts

Hello. I want to buy this notebook HP 15-N067sl (http://h10025.www1.hp.com/ewfrf/wc/document?cc=us&dlc=en&docname=c03967327&lc=en&jumpid=reg_r1002_usen_c-001_title_r0001)

 

Can anyone tell me if is compatible with 10.9?

 

Thanks

It is, but your post is off-topic.

I have no clue how to do this. My research didn't yield anything useful. Sorry.

How to do what? For patching the kernel, see: http://www.insanelymac.com/forum/topic/293503-haswell-early-reboot-mavericks-locked-msrs-and-hp-envy-15-j063cl-i7-4700mq/

Link to comment
Share on other sites

 

Appreciate the thought but I already did this myself as well, I just took it a step further and didn't have time to document it. I updated to whatever custom build (can't recall it right now) of 10.9.1 the MBP11,x use and force installed it on my machine using Pacifist. Of course, I checked it first to make sure none of the changes would be catastrophic to my install. Afterwards, I re-ran the installer to make sure everything got the correct perms. So far, it's been running just as it did before I updated. Given, I'm using a MBP11,3 smbios instead of the 11,2. Thanks anyway though. Someone else will surely find it useful! :)

 

I just need to get this cursed Optimus figured out and get my GeForce working. Then, everything in my world will be super wonderful as opposed to just wonderful ;p

 

Link to comment
Share on other sites

Appreciate the thought but I already did this myself as well, I just took it a step further and didn't have time to document it. I updated to whatever custom build (can't recall it right now) of 10.9.1 the MBP11,x use and force installed it on my machine using Pacifist. Of course, I checked it first to make sure none of the changes would be catastrophic to my install. Afterwards, I re-ran the installer to make sure everything got the correct perms. So far, it's been running just as it did before I updated. Given, I'm using a MBP11,3 smbios instead of the 11,2. Thanks anyway though. Someone else will surely find it useful! :)

I'm pretty sure that the only thing necessary is two simple edits to PlatformSupport.plist and adding the <board-id>.plist to X86PlatformPlugIn.kext/Contents/Resources.

 

I just need to get this cursed Optimus figured out and get my GeForce working. Then, everything in my world will be super wonderful as opposed to just wonderful ;p

Good luck with that one... It would require understanding the interface from the various graphics drivers involved and their relationship with the GMUX driver...not documented AFAIK... then writing a "fake" GMUX driver that uses ACPI methods to switch graphics devices, assuming the interface of the GMUX device is replaceable, and has a design "compatible" with the way ACPI based graphics switching works.

 

I have a few other things on my list... not sure if I'll get to them:

 

- brightness working with ACPIBacklight.kext (made good progress here with HD3000/HD4000, but haven't found the hardware registers to manipulate on HD4600).

- better/louder audio for patched AppleHDA.kext (beats audio subwoofer?)

- brightness keys (without utilizing F2/F3)... may have to compromise here and use Ctrl+Shift+F2/F3 (or Ctrl+Cmd+F2/F3)

- native USB3 (or fix bugs in GenericUSBXHCI that causes media to be "ejected improperly" across sleep/wake

Link to comment
Share on other sites

I'm pretty sure that the only thing necessary is two simple edits to PlatformSupport.plist and adding the .plist to X86PlatformPlugIn.kext/Contents/Resources.Good luck with that one... It would require understanding the interface from the various graphics drivers involved and their relationship with the GMUX driver...not documented AFAIK... then writing a "fake" GMUX driver that uses ACPI methods to switch graphics devices, assuming the interface of the GMUX device is replaceable, and has a design "compatible" with the way ACPI based graphics switching works.I have a few other things on my list... not sure if I'll get to them:- brightness working with ACPIBacklight.kext (made good progress here with HD3000/HD4000, but haven't found the hardware registers to manipulate on HD4600).- better/louder audio for patched AppleHDA.kext (beats audio subwoofer?)- brightness keys (without utilizing F2/F3)... may have to compromise here and use Ctrl+Shift+F2/F3 (or Ctrl+Cmd+F2/F3)- native USB3 (or fix bugs in GenericUSBXHCI that causes media to be "ejected improperly" across sleep/wake
You are likely 100% correct and I considered only swapping those files out but I also noticed that many of the kexts got updated using that build too so I figured I would see if they helped with my GeForce. Wishful thinking really but luckily, no new issues have arisen from the applying the update. An interesting kext update is AppleHDA. They seem to have removed the entire Resources folder from the new build of it. Can't possibly imagine why they'd do that. *sarcasm* >_>Heh, yeah I certainly doubt I'll ever get lucky and just happen to get it working using the testing methods I've previously attempted. No no, sadly, I'll have to continue waiting and hoping someone wiser than me comes up with a nifty trick to get it working. Hope is all I have left for that one.- I would love to get my brightness working properly again too. Sadly, I haven't found a better method than what I'm currently using.- Good luck with that. Perhaps I simply missed something during the patching process but I spent awhile messing around with the nodes trying to get the sub to work but I never could. I'm not terribly concerned with the volume level. It's loud enough for me but I can see why you'd want it louder. I repatched mine recently to add a mic boost to it since people had trouble hearing me over video conferencing. - Fn+F2/F3 have been working well for me. It just messes me up whenever I switch to another OS that doesn't require me to add in the Fn key. - This one I don't believe is related to GenericUSBXHCI. Not if you suffer from the same annoyance I suffer from. Try this: connect something mountable (HDD/flash drive) to your USB on the right side, then try connecting something else mountable using the other port on the right side and tell me what happens. Mine always disconnects the first device no matter the OS. Even in Windows with the "official" driver, it happens and it is very aggravating. If yours does it too, I believe it's a USB current issue and not software related.

 

@gygabyte666Could you try this one to see if it works on your RTS5227? (need to add vendor-id and device-id)http://forum.osxlatitude.com/index.php?/topic/5859-sd-card-reader-on-latitude-e6410
Thanks, I will test this and get back to you. My expectations are low though since I've already tried out one version of VoodooSDHC but I'm very willing to hope they added support in for my card. I'll let you know. :)
Link to comment
Share on other sites

You are likely 100% correct and I considered only swapping those files out

100% verified. When I switched to Clover w/ MacBookPro11,2, my 10.8.5 install broke. But I was able to simply add the plist from X86PlatfromPlugin and modify the PlatformSupport.plist to get it working again. Native XCPM still working, although the 17-pstate is missing. I assume that comes from changes in the mach_kernel, not there in 10.8.5.

 

but I also noticed that many of the kexts got updated using that build too so I figured I would see if they helped with my GeForce. Wishful thinking really but luckily, no new issues have arisen from the applying the update.

I applied the 10.9.1 retina update here. New mach_kernel (13.0.2), so had to figure out a new patch for it. Updated my blog.

 

An interesting kext update is AppleHDA. They seem to have removed the entire Resources folder from the new build of it. Can't possibly imagine why they'd do that. *sarcasm* >_>

Updates only contain files that are changed. So when you look at an update like AppleHDA it just means the files in Resources/* didn't change. The update process is a "merge" with what you have originally and the updated files (eg. replacing only the new files, leaving the others intact). This is why you can't apply the kexts from updates with tools like Kext Wizard.

 

- This one I don't believe is related to GenericUSBXHCI. Not if you suffer from the same annoyance I suffer from. Try this: connect something mountable (HDD/flash drive) to your USB on the right side, then try connecting something else mountable using the other port on the right side and tell me what happens. Mine always disconnects the first device no matter the OS.

I'll give that a try with both GenericUSBXHCI and AppleUSBXHCI. I have AppleUSBXHCI working after sleep using a kext patch (http://www.insanelymac.com/forum/topic/285157-patched-appleusbxhci-from-os-1082/page-6?do=findComment&comment=1951416). Unfortunately, it has the same issue of ejecting drives prematurely across sleep/wake.

 

Even in Windows with the "official" driver, it happens and it is very aggravating. If yours does it too, I believe it's a USB current issue and not software related.

I'll be sure to check that out.

 

Thanks, I will test this and get back to you. My expectations are low though since I've already tried out one version of VoodooSDHC but I'm very willing to hope they added support in for my card. I'll let you know. :)

Let me know if you know where current up-to-date source code lives... The voodoo projects are always difficult to determine where the "real"/actively maintained project lives.

Link to comment
Share on other sites

100% verified. When I switched to Clover w/ MacBookPro11,2, my 10.8.5 install broke. But I was able to simply add the plist from X86PlatfromPlugin and modify the PlatformSupport.plist to get it working again. Native XCPM still working, although the 17-pstate is missing. I assume that comes from changes in the mach_kernel, not there in 10.8.5.

 

 

I applied the 10.9.1 retina update here. New mach_kernel (13.0.2), so had to figure out a new patch for it. Updated my blog.

 

 

Updates only contain files that are changed. So when you look at an update like AppleHDA it just means the files in Resources/* didn't change. The update process is a "merge" with what you have originally and the updated files (eg. replacing only the new files, leaving the others intact). This is why you can't apply the kexts from updates with tools like Kext Wizard.

 

 

I'll give that a try with both GenericUSBXHCI and AppleUSBXHCI. I have AppleUSBXHCI working after sleep using a kext patch (http://www.insanelymac.com/forum/topic/285157-patched-appleusbxhci-from-os-1082/page-6?do=findComment&comment=1951416). Unfortunately, it has the same issue of ejecting drives prematurely across sleep/wake.

 

 

I'll be sure to check that out.

 

 

Let me know if you know where current up-to-date source code lives... The voodoo projects are always difficult to determine where the "real"/actively maintained project lives.

Hmm, so the new state is added in because of the new kernel? Interesting. I may have to start using it then. Thanks for that info. :)

 

Oops...duh, I knew that too. Honest mistake. I'm so use to having to apply combo updates that I clearly have totally forgotten how singles work.

 

Please let me know if you try it. I'd be interested to see if you have the same problem. I've never used GenericUSBXHCI so i'm not really familiar with it or the problems it may have with my model. I rely explicitly on AppleUSBXHCI and so far, it works well enough for me and retains all the functionality (and issues) that I experience using Windows & Linux. I hope it's not just me having this problem though. That would mean I have a defect and would have to send it in for repair.  :(

 

I agree. Voodoo labs have helped out the community with many things, many different times but their files are also the most difficult to obtain. The clearly do not maintain very well. The linked version of VoodooSDHC seems to be identical to the one I tested way back on 10.8-10.8.5. Same build rev too but I will try it out anyway and see if it surprises me in someway. I'll keep you posted with results.

Link to comment
Share on other sites

This one I don't believe is related to GenericUSBXHCI. Not if you suffer from the same annoyance I suffer from. Try this: connect something mountable (HDD/flash drive) to your USB on the right side, then try connecting something else mountable using the other port on the right side and tell me what happens. Mine always disconnects the first device no matter the OS. Even in Windows with the "official" driver, it happens and it is very aggravating. If yours does it too, I believe it's a USB current issue and not software related.

Interesting...

 

I'm able to reproduce that exact problem as well. I can see it on Windows, 10.9.1, and 10.8.5. With AppleUSBXHCI and GenericUSBXHCI. It also affects non-mountable devices such as USB mice. You can see the object disappear(red)/reappear(green) in IORegistryExplorer. On 10.8.5 it is more annoying as the first device plugged in doesn't come back. On 10.9.1, the first device recovers and both devices are present, not to mention that the notification is less obtrusive in 10.9.1 than 10.8.5.

Hmm, so the new state is added in because of the new kernel? Interesting. I may have to start using it then. Thanks for that info. :)

Actually, I see pstate 17 with the 13.0.0 kernel too (just tested it). But not with the 10.8.5 kernel. So it is new with the 10.9.x mach_kernel.

Link to comment
Share on other sites

Interesting...

 

I'm able to reproduce that exact problem as well. I can see it on Windows, 10.9.1, and 10.8.5. With AppleUSBXHCI and GenericUSBXHCI. It also affects non-mountable devices such as USB mice. You can see the object disappear(red)/reappear(green) in IORegistryExplorer. On 10.8.5 it is more annoying as the first device plugged in doesn't come back. On 10.9.1, the first device recovers and both devices are present, not to mention that the notification is less obtrusive in 10.9.1 than 10.8.5.

 

Actually, I see pstate 17 with the 13.0.0 kernel too (just tested it). But not with the 10.8.5 kernel. So it is new with the 10.9.x mach_kernel.

Ok good. It's not just me. *whew* Still, it's not a good thing no matter how you look at it. Because of it I have to be cautious about which devices I plug in since if I plug in two HDDs in those ports, one will disconnect and it could potentially lead to data loss. Not a fun bug by any means at all. I'm hopeful that HP can fix it through a BIOS update. It's really quite annoying.

 

I just realized this myself too. I patched the 10.9.1 kernel as your blog instructed, rebooted to use it and noticed no change with my pstates. Oh well, it was still worth patching the kernel.

 

Oh and the linked VoodooSDHC does NOT work for my card adapter. As I suspected it is exactly the same build as the one I tried in a previous install. I just tested it out and although it loads like it's supposed to, even in ioreg, it doesn't support the card bus so it throws an error in verbose. Thanks for keeping an eye out though. :)

Link to comment
Share on other sites

@gygabyte666

 

Thought I would update you on my progress with the backlight problem.  I currently have it working at fresh boot without display sleep or blink screen.

 

I'm using a patched AppleBacklight.kext (actually a codeless kext AppleBacklightInjector.kext) to get the proper data to AppleBacklight and a DSDT patch to initialize the IGPU backlight controls as OS X seems to expect.

 

I notice you're using also a patched AppleBacklight.kext, but you have two entires in there, one F10T219d and another F15T219d.  According to your DSDT, you should end up using the F10T219d one (the '10' vs. '15' is driven by what PNLF._UID is set to).  And in that data, the max brightness only goes to 0x3aa.  I'm finding that the hardware is initialized such that the max brightness would be 0xa9d, unless this initialization is dynamic on Haswell (could be, haven't tested it).  With Sandy/Ivy it is not dynamic and fixed at 0x710.  I suspect Haswell is fixed as well.  Do you find your brightness is high enough going to only 0x3aa?   Will it go higher if you use the other brightness profile (the F15T219d one)?  You can change _UID to 15 (from 10) in your DSDT to test.  I'm using a data set that is more like the F15 one in your patched kext (this is based on looking at what data my MacBookAir6,2 uses).

 

At any rate, the trick I've found is initializing one of the IGPU registers in PNLF._INI.  This is after finding some documentation on where these registers are located and what they are used for... and a little bit of work with ACPIDebug.kext to discover how OS X sets them after display sleep/wake.

 

Here is the patch I'm using currently for PNLF:

 

# apply to ssdt4.dsl
 
into device label IGPU code_regex (OperationRegion\s\(IGD2,\sPCI_Config[^\}]*\}) remove_matched;
into device label IGPU code_regex (OperationRegion\s\(IGDP,\sPCI_Config[^\}]*\}) replace_matched
begin
%1\n
OperationRegion (IGD2, PCI_Config, 0x10, 4)\n
Field (IGD2, AnyAcc, NoLock, Preserve)\n
{\n
BAR1,32,\n
}\n
end;
into device label PNLF remove_entry;
into definitionblock code_regex . insert
begin
Scope (\_SB)\n
{\n
    Device (PNLF)\n
    {\n
        // normal PNLF declares (note some of this probably not necessary)\n
        Name (_ADR, Zero)\n
        Name (_HID, EisaId ("APP0002"))\n
        Name (_CID, "backlight")\n
        Name (_UID, 10)\n
        Name (_STA, 0x0B)\n
        //define hardware register access for brightness\n
        // you can see BAR1 value in RW-Everything under Bus00,02 Intel VGA controler PCI\n
        OperationRegion (BRIT, SystemMemory, \_SB.PCI0.IGPU.BAR1, 0xc8254)\n
        Field (BRIT, AnyAcc, Lock, Preserve)\n
        {\n
            Offset(0x4824c),\n
            LEV2, 32,\n
            LEVL, 32,\n
            Offset (0x7003C),\n
            P0BL, 32,\n
            Offset(0xc824c),\n
            LEVW, 32,\n
            LEVX, 32,\n
        }\n
        Method (_INI, 0, NotSerialized)\n
        {\n
            // This 0xC value comes from looking what OS X initializes this\n
            // register to after display sleep (using ACPIDebug/ACPIPoller)\n
            Store(0xC0000000, LEVW)\n
        }\n
    }\n
}\n
end;
 

The patch is applied to SSDT-4.aml (where the GFX0 device lives) after renaming GFX0 to IGPU.  Then the SSDT-4.aml is loaded by placing it in ACPI/patched.  Special care must be used in disassembling the SSDT as well.  You need to use the -e param to iasl and give it the other SSDTs and DSDT to help with the decompilation.  The same technique works for the DSDT.  Your GFX0 device may be in a different SSDT because you have nvidia and my computer does not.

 

It could also be that your value of LEVW is different, but try it and see.  Be prepared for your backlight to not function (you can type Shift+Ctrl+Fn+prt sc/ins to force a display sleep).  If it doesn't work, you may need to use ACPIDebug/ACPIPoller to get your value of LEVW after display sleep, but I'm hoping/betting that OS X initializes it to the same value regardless of the computer (the bits there assign the backlight to a given pipe A/B/C).

 

Let me know what you think...

 

My next step is to enhance this patch a bit more to enable ACPIBacklight.kext to work again (my fork of it, of course).  There's a few extra features we get by using it instead of AppleBacklight.kext.

 

Note: If you previously put PNLF in DSDT, you'll need to remove it. If an SSDT has a duplicate method/device, the SSDT will not load. And currently, you must use Clover v2379 or prior due to this Clover bug: http://www.projectosx.com/forum/index.php?showtopic=2562&view=findpost&p=38791

  • Like 1
Link to comment
Share on other sites

@gygabyte666

 

Here's the patches for use with ACPIBacklight, my fork here: https://github.com/RehabMan/OS-X-ACPI-Backlight

 

You can switch between ACPIBacklight and AppleBacklight just by renaming/removing ACPIBacklight. That is, this patch is a superset of the AppleBacklight patch and works with both AppleBacklight and ACPIBacklight.

 

Main code bits:

# apply to ssdt4.dsl

into device label IGPU code_regex (OperationRegion\s\(IGD2,\sPCI_Config[^\}]*\}) remove_matched;
into device label IGPU code_regex (OperationRegion\s\(IGDP,\sPCI_Config[^\}]*\}) replace_matched
begin
%1\n
OperationRegion (IGD2, PCI_Config, 0x10, 4)\n
Field (IGD2, AnyAcc, NoLock, Preserve)\n
{\n
	BAR1,32,\n
}\n
end;

into device label PNLF remove_entry;
into definitionblock code_regex . insert
begin
Scope (\_SB)\n
{\n
    Device (PNLF)\n
    {\n
        // normal PNLF declares (note some of this probably not necessary)\n
        Name (_ADR, Zero)\n
        Name (_HID, EisaId ("APP0002"))\n
        Name (_CID, "backlight")\n
        Name (_UID, 10)\n
        Name (_STA, 0x0B)\n
        //define hardware register access for brightness\n
        // you can see BAR1 value in RW-Everything under Bus00,02 Intel VGA controler PCI\n
        OperationRegion (BRIT, SystemMemory, \_SB.PCI0.IGPU.BAR1, 0xc8254)\n
        Field (BRIT, AnyAcc, Lock, Preserve)\n
        {\n
            Offset(0x4824c),\n
            LEV2, 32,\n
            LEVL, 32,\n
            Offset (0x7003C),\n
            P0BL, 32,\n
            Offset(0xc824c),\n
            LEVW, 32,\n
            LEVX, 32,\n
        }\n
        Method (_INI, 0, NotSerialized)\n
        {\n
            // If the BIOS actually sets the values prior to boot, this would be\n
            // how (maybe) to capture them.  My Envy does not have the capability\n
            // to set brightness and I find these values are not set.\n
            // The current value could also be in LEVL, and probably is even\n
            // though OS X seems to manipulate only the low 16-bits of LEVX to\n
            // change brightness.\n
            // Because the low-order 16-bits are set to zero on the Envy, enabling\n
            // this code causes a blank screen before the login screena appears.\n
            //\n
            //Store(LEVX, Local0)\n
            //Store(ShiftRight(Local0,16), Local1)\n
            //Store(And(Local0,0xFFFF), Local2)\n
            //Divide(Multiply(Local2, 0xad9), Local1, Local0)\n
            //Or(Local0, 0xad90000, Local0)\n
            //\n
            //REVIEW: wait for vblank to change things\n
            //While(LEqual (P0BL, Local1)) {}\n
            //\n
            // This is part of the "keep startup level"...\n
            // see comment above.\n
            //Store(Local0, LEVX)\n
            //\n
            // This 0xC value comes from looking what OS X initializes this\n
            // register to after display sleep (using ACPIDebug/ACPIPoller)\n
            Store(0xC0000000, LEVW)\n
            // Because this laptop starts at full brightness, I just set it right\n
            // here.  This is to insure _BQC and XBQC return the correct level\n
            // at startup.\n
            Store(0xad90ad9, LEVX)\n
        }\n
        // _BCM/_BQC: set/get for brightness level\n
        Method (_BCM, 1, NotSerialized)\n
        {\n
            // store new backlight level\n
            Store(Match(_BCL, MGE, Arg0, MTR, 0, 2), Local0)\n
            If (LEqual(Local0, Ones)) { Subtract(SizeOf(_BCL), 1, Local0) }\n
            Store(Or(DerefOf(Index(_BCL,Local0)),And(LEVX,0xFFFF0000)), LEVX)\n
        }\n
        Method (_BQC, 0, NotSerialized)\n
        {\n
            Store(Match(_BCL, MGE, And(LEVX, 0xFFFF), MTR, 0, 2), Local0)\n
            If (LEqual(Local0, Ones)) { Subtract(SizeOf(_BCL), 1, Local0) }\n
            Return(DerefOf(Index(_BCL, Local0)))\n
        }\n
        Method (_DOS, 1, NotSerialized)\n
        {\n
            ^^PCI0.IGPU._DOS(Arg0)\n
        }\n
        // extended _BCM/_BQC for setting "in between" levels\n
        Method (XBCM, 1, NotSerialized)\n
        {\n
            // store new backlight level\n
            If (LGreater(Arg0, XRGH)) { Store(XRGH, Arg0) }\n
            If (LLess(Arg0, XRGL)) { Store(XRGL, Arg0) }\n
            Store(Or(Arg0,And(LEVX,0xFFFF0000)), LEVX)\n
        }\n
        Method (XBQC, 0, NotSerialized)\n
        {\n
            Store(And(LEVX,0xFFFF), Local0)\n
            If (LGreater(Local0, XRGH)) { Store(XRGH, Local0) }\n
            If (LLess(Local0, XRGL)) { Store(XRGL, Local0) }\n
            Return(Local0)\n
        }\n
    }\n
}\n
end;
Data bits:

into device label PNLF code_regex Name\s\(_BCL,\sPackage[^\}]*\}\) remove_matched;
into device label PNLF code_regex Name\s\(XRGL,.*\)\n removeall_matched;
into device label PNLF code_regex Name\s\(XRGH,.*\)\n removeall_matched;
into device label PNLF code_regex Name\s\(KLVX,.*\)\n removeall_matched;
into device label PNLF code_regex . insert
begin
    // XRGL/XRGH: defines the valid range\n
    Name (XRGL, Zero)\n
    Name (XRGH, 2777)\n
    // _BCL: returns list of valid brightness levels\n
    // first two entries describe ac/battery power levels\n
    Name (_BCL, Package()\n
    {\n
        2777,\n
        748,\n
        0,\n
        35, 39, 44, 50,\n
        58, 67, 77, 88,\n
        101, 115, 130, 147,\n
        165, 184, 204, 226,\n
        249, 273, 299, 326,\n
        354, 383, 414, 446,\n
        479, 514, 549, 587,\n
        625, 665, 706, 748,\n
        791, 836, 882, 930,\n
        978, 1028, 1079, 1132,\n
        1186, 1241, 1297, 1355,\n
        1414, 1474, 1535, 1598,\n
        1662, 1728, 1794, 1862,\n
        1931, 2002, 2074, 2147,\n
        2221, 2296, 2373, 2452,\n
        2531, 2612, 2694, 2777,\n
    })\n
end;
  • Like 1
Link to comment
Share on other sites

@RehabMan,

 

Sorry for the late reply but I wanted to quickly let you know I saw your posts and I look forward to testing them. Unfortunately, I've been in the process of some major updates and I'm not exactly sure when I'll be able to. I wanted to let you know I appreciate the info and your hard work. This is a pretty significant issue with my system and it would be really nice if your methods worked to fix it. As soon as I can, I'll test it out and post my results. Thanks!

Link to comment
Share on other sites

@gygabyte666

 

Thought I would update you on my progress with the backlight problem.  I currently have it working at fresh boot without display sleep or blink screen.

 

I'm using a patched AppleBacklight.kext (actually a codeless kext AppleBacklightInjector.kext) to get the proper data to AppleBacklight and a DSDT patch to initialize the IGPU backlight controls as OS X seems to expect.

 

I notice you're using also a patched AppleBacklight.kext, but you have two entires in there, one F10T219d and another F15T219d.  According to your DSDT, you should end up using the F10T219d one (the '10' vs. '15' is driven by what PNLF._UID is set to).  And in that data, the max brightness only goes to 0x3aa.  I'm finding that the hardware is initialized such that the max brightness would be 0xa9d, unless this initialization is dynamic on Haswell (could be, haven't tested it).  With Sandy/Ivy it is not dynamic and fixed at 0x710.  I suspect Haswell is fixed as well.  Do you find your brightness is high enough going to only 0x3aa?   Will it go higher if you use the other brightness profile (the F15T219d one)?  You can change _UID to 15 (from 10) in your DSDT to test.  I'm using a data set that is more like the F15 one in your patched kext (this is based on looking at what data my MacBookAir6,2 uses).

 

At any rate, the trick I've found is initializing one of the IGPU registers in PNLF._INI.  This is after finding some documentation on where these registers are located and what they are used for... and a little bit of work with ACPIDebug.kext to discover how OS X sets them after display sleep/wake.

 

Here is the patch I'm using currently for PNLF:

 

# apply to ssdt4.dsl
 
into device label IGPU code_regex (OperationRegion\s\(IGD2,\sPCI_Config[^\}]*\}) remove_matched;
into device label IGPU code_regex (OperationRegion\s\(IGDP,\sPCI_Config[^\}]*\}) replace_matched
begin
%1\n
OperationRegion (IGD2, PCI_Config, 0x10, 4)\n
Field (IGD2, AnyAcc, NoLock, Preserve)\n
{\n
BAR1,32,\n
}\n
end;
into device label PNLF remove_entry;
into definitionblock code_regex . insert
begin
Scope (\_SB)\n
{\n
    Device (PNLF)\n
    {\n
        // normal PNLF declares (note some of this probably not necessary)\n
        Name (_ADR, Zero)\n
        Name (_HID, EisaId ("APP0002"))\n
        Name (_CID, "backlight")\n
        Name (_UID, 10)\n
        Name (_STA, 0x0B)\n
        //define hardware register access for brightness\n
        // you can see BAR1 value in RW-Everything under Bus00,02 Intel VGA controler PCI\n
        OperationRegion (BRIT, SystemMemory, \_SB.PCI0.IGPU.BAR1, 0xc8254)\n
        Field (BRIT, AnyAcc, Lock, Preserve)\n
        {\n
            Offset(0x4824c),\n
            LEV2, 32,\n
            LEVL, 32,\n
            Offset (0x7003C),\n
            P0BL, 32,\n
            Offset(0xc824c),\n
            LEVW, 32,\n
            LEVX, 32,\n
        }\n
        Method (_INI, 0, NotSerialized)\n
        {\n
            // This 0xC value comes from looking what OS X initializes this\n
            // register to after display sleep (using ACPIDebug/ACPIPoller)\n
            Store(0xC0000000, LEVW)\n
        }\n
    }\n
}\n
end;
 

The patch is applied to SSDT-4.aml (where the GFX0 device lives) after renaming GFX0 to IGPU.  Then the SSDT-4.aml is loaded by placing it in ACPI/patched.  Special care must be used in disassembling the SSDT as well.  You need to use the -e param to iasl and give it the other SSDTs and DSDT to help with the decompilation.  The same technique works for the DSDT.  Your GFX0 device may be in a different SSDT because you have nvidia and my computer does not.

 

It could also be that your value of LEVW is different, but try it and see.  Be prepared for your backlight to not function (you can type Shift+Ctrl+Fn+prt sc/ins to force a display sleep).  If it doesn't work, you may need to use ACPIDebug/ACPIPoller to get your value of LEVW after display sleep, but I'm hoping/betting that OS X initializes it to the same value regardless of the computer (the bits there assign the backlight to a given pipe A/B/C).

 

Let me know what you think...

 

My next step is to enhance this patch a bit more to enable ACPIBacklight.kext to work again (my fork of it, of course).  There's a few extra features we get by using it instead of AppleBacklight.kext.

 

Note: If you previously put PNLF in DSDT, you'll need to remove it. If an SSDT has a duplicate method/device, the SSDT will not load. And currently, you must use Clover v2379 or prior due to this Clover bug: http://www.projectosx.com/forum/index.php?showtopic=2562&view=findpost&p=38791

 

Not bad RehabMan! This works for me. I guess my BAR info is the same as yours. I simply removed my old PNFL patch I had in my DSDT, applied the PNFL patch you listed to my SSDT-1 (My IGPU/GFX0 is in that, not my SSDT-4 like yours) and tested it out. I honestly don't know what my max brightness is. I did a bit of testing way back on 10.8.5 to see if I could figure it out but I never really got far. Using this method of yours though makes it seem like it's pretty close to max though. Actually, it would be really nice if the values went a bit lower. Even the lowest value (prior to the backlight going off) is really quite bright. Maybe real Macs are like that nowadays, if that's the case, i'm glad I haven't upgraded to one yet. Speaking of the the value that shuts the backlight completely off, I really wish I could make my backlight turn off when running Windows too.

 

You mention i'm using a modified AppleBacklight.kext and that was correct. Emphasis on the was part. I used that during my first real, backlight tests. I haven't been using it since I found Andy's FixEDID linked here. It generates a nice little kextless injector for me to use instead and I have been using it since I obtained it. Since you listed you too are using a kextless injector, I assume maybe you too are using it or have at least tried it? It makes all the tedious, little tweaking I had to do before much easier.

 

Worth mentioning that I noticed a new, interesting verbose message with this new technique. Oddly enough, it was listed on the same line as one of my wifi-enabled messages. Check it out:

ARPT: 1.649797: wl0: Broadcom BCM43b1, vendorID[0x14e4] BAR0[0xd3600004] 

You have this message too I assume? Well, minus the wifi info anyway. Thanks for posting this info up! It'll be nice to not have put the machine to sleep in order to adjust the brightness.

 

I haven't had a chance yet to test your ACPIBacklight method but I really want to. I'm a bit confused by what you wrote though. Does it mean I can keep my EDID injector in /S/L/E during my tests with ACPIBacklight? Does ACPI have better features over AppleBacklight?

Link to comment
Share on other sites

Not bad RehabMan! This works for me. I guess my BAR info is the same as yours.

Thanks for testing... I'm now confident to put it into my main laptop repo.

 

No. The patch calculates and uses the BAR1 that your system uses automatically.

 

I simply removed my old PNFL patch I had in my DSDT, applied the PNFL patch you listed to my SSDT-1 (My IGPU/GFX0 is in that, not my SSDT-4 like yours) and tested it out. I honestly don't know what my max brightness is. I did a bit of testing way back on 10.8.5 to see if I could figure it out but I never really got far. Using this method of yours though makes it seem like it's pretty close to max though.

Did you use ACPIBacklight or patched AppleBacklight? (Edit: I see you're using an injector for AppleBacklight).

 

You should be getting max brightness because I'm using the levels that OS X uses (0xad9) and with either method that level as the top level (assuming you provided data in AppleBacklight that goes to the top level). Interestingly my MacBookAir6,2 only goes to 0xa6a, so I could patch AppleBacklight.kext on my real mac to force it to go to max brightness 0xad9!

 

Your brightness level using AppleBacklight will depend on the data you have in your injector. 0xad9 is max.

 

Actually, it would be really nice if the values went a bit lower. Even the lowest value (prior to the backlight going off) is really quite bright. Maybe real Macs are like that nowadays, if that's the case, i'm glad I haven't upgraded to one yet.

You can modify the value in your AppleBacklight, or modify the value in _BCL for ACPIBacklight. Not sure which solution you're using... Also, if you're using ACPIBacklight you can push the level lower using the brightness slider or by pressing Shift+Option+BrightDown.

 

Speaking of the the value that shuts the backlight completely off, I really wish I could make my backlight turn off when running Windows too.

Haha.. I wonder if there is a shortcut key for display sleep in Windows (like Shift+Ctrl+Eject on Mac... on our keyboards: Shift+Ctrl+Fn+Ins/PrtSc).

 

You mention i'm using a modified AppleBacklight.kext and that was correct. Emphasis on the was part. I used that during my first real, backlight tests. I haven't been using it since I found Andy's FixEDID linked here. It generates a nice little kextless injector for me to use instead and I have been using it since I obtained it. Since you listed you too are using a kextless injector, I assume maybe you too are using it or have at least tried it? It makes all the tedious, little tweaking I had to do before much easier.

I wrote a shell script to generate a codeless kext (injector). I didn't know about Andy's FixEDID.

 

Worth mentioning that I noticed a new, interesting verbose message with this new technique. Oddly enough, it was listed on the same line as one of my wifi-enabled messages. Check it out:

ARPT: 1.649797: wl0: Broadcom BCM43b1, vendorID[0x14e4] BAR0[0xd3600004] 
You have this message too I assume? Well, minus the wifi info anyway. Thanks for posting this info up! It'll be nice to not have put the machine to sleep in order to adjust the brightness.

 

I haven't looked, but it is unrelated to IGPU backlight.

 

I haven't had a chance yet to test your ACPIBacklight method but I really want to. I'm a bit confused by what you wrote though. Does it mean I can keep my EDID injector in /S/L/E during my tests with ACPIBacklight? Does ACPI have better features over AppleBacklight?

Yes, you can keep your EDID injector in SLE. ACPIBacklight (my version) has some nice features over using AppleBacklight:

- smooth transitions between levels (like a real Mac)

- levels in between the main levels, including levels lower than the lowest major level (real Macs should have this, but Cupertino has a bug...)

 

You can read more about my ACPIBacklight on github.

Link to comment
Share on other sites

Thanks for testing... I'm now confident to put it into my main laptop repo.

No problem! Happy to be the guinea pig. ;p

Thanks again for the info. Very good stuff! :)

 

No. The patch calculates and uses the BAR1 that your system uses automatically.

Ah! Well, that explains a lot. It idenified it pretty well.

 

You should be getting max brightness because I'm using the levels that OS X uses (0xad9) and with either method that level as the top level (assuming you provided data in AppleBacklight that goes to the top level). Interestingly my MacBookAir6,2 only goes to 0xa6a, so I could patch AppleBacklight.kext on my real mac to force it to go to max brightness 0xad9!

Nice! So, are you gonna play around with your MBA6,2's backlight levels and force them higher? That'd be interesting. :D

 

Your brightness level using AppleBacklight will depend on the data you have in your injector. 0xad9 is max.

Not entirely sure what I have in there anymore. It's been awhile since I played around with it. I'll have to check and if 0xad9 isn't in there, i'll probably set it as a temp test.

 

You can modify the value in your AppleBacklight, or modify the value in _BCL for ACPIBacklight. Not sure which solution you're using... Also, if you're using ACPIBacklight you can push the level lower using the brightness slider or by pressing Shift+Option+BrightDown.

More good info. I am only able to use the AppleBacklight method as of currently.

 

Haha.. I wonder if there is a shortcut key for display sleep in Windows (like Shift+Ctrl+Eject on Mac... on our keyboards: Shift+Ctrl+Fn+Ins/PrtSc).

There is probably a key combo to put the display to sleep but we both know that isn't the same thing. I wonder if using a slightly modified dsdt/ssdt in the WINDOWS folder would work with Clover to lower the min brightness value. This may need to be tested.

 

I wrote a shell script to generate a codeless kext (injector). I didn't know about Andy's FixEDID.

Ah, I see. Well, I did things the hard way on my first round too. Manually patching AppleBacklight was...a chore. ;p

 

I haven't looked, but it is unrelated to IGPU backlight.

Think so? I only noticed it after I tried out your AppleBacklight fix. Hmm...

 

Yes, you can keep your EDID injector in SLE. ACPIBacklight (my version) has some nice features over using AppleBacklight:

- smooth transitions between levels (like a real Mac)

- levels in between the main levels, including levels lower than the lowest major level (real Macs should have this, but Cupertino has a bug...)

Good stuff! Sadly, I couldn't get the ACPIBacklight method working for me yet. I only tested it once so far but I plan to try again later. I can imagine that one of my previous tests is still lingering in my ssdt somewhere and messing things up. I have to find it and remove it. It's probably something I added into my IGPU to get the original ACPIBacklight working with 10.8.5. I'll investigate when possible and report back. Hopefully, it's not a missed typo in the second patch you put up. There was a lot of comments in it, maybe one of them seeped through and wasn't commented out? (guessing right now)

 

You can read more about my ACPIBacklight on github.

I did that after I left the reply. >_<

Link to comment
Share on other sites

Good stuff! Sadly, I couldn't get the ACPIBacklight method working for me yet. I only tested it once so far but I plan to try again later. I can imagine that one of my previous tests is still lingering in my ssdt somewhere and messing things up. I have to find it and remove it. It's probably something I added into my IGPU to get the original ACPIBacklight working with 10.8.5. I'll investigate when possible and report back. Hopefully, it's not a missed typo in the second patch you put up. There was a lot of comments in it, maybe one of them seeped through and wasn't commented out? (guessing right now)

It could be your injector is interfering. I carefully chose my IOProbeScore as follows:

 

AppleBacklight: 2000

AppleBacklightInjector: 2500

ACPIBacklight: 3000

 

If your injector uses a value 3000 or larger it may cause AppleBacklight to load instead of ACPIBacklight.

Link to comment
Share on other sites

It could be your injector is interfering. I carefully chose my IOProbeScore as follows:

 

AppleBacklight: 2000

AppleBacklightInjector: 2500

ACPIBacklight: 3000

 

If your injector uses a value 3000 or larger it may cause AppleBacklight to load instead of ACPIBacklight.

My injector's plist doesn't have IOProbeScore listed. Would adding it in help you think? Otherwise I might have to ask to use your files as a reference to try to fix this. Is your AppleBacklight still a vanilla kext or did you edit that too along with using the injector? Thanks!

Link to comment
Share on other sites

My injector's plist doesn't have IOProbeScore listed. Would adding it in help you think? Otherwise I might have to ask to use your files as a reference to try to fix this. Is your AppleBacklight still a vanilla kext or did you edit that too along with using the injector? Thanks!

My AppleBacklight.kext is vanilla. Try without the injector installed. As I mentioned I never looked at FixEDID, so I'm not really certain what's even in your injector (maybe it does something completely different than mine [which is quite simple]). Use IORegistryExplorer to verify that ACPIBacklight is attached to the PNLF.

 

For reference this is the Info.plist from my AppleBacklightInjector.kext:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleExecutable</key>
	<string>AppleBacklight</string>
	<key>CFBundleGetInfoString</key>
	<string>0.9.0, OpenSource 2014 RehabMan. All rights reserved.</string>
	<key>CFBundleIdentifier</key>
	<string>org.rehabman.driver.AppleBacklightInjector</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>AppleBacklightInjector</string>
	<key>CFBundlePackageType</key>
	<string>KEXT</string>
	<key>CFBundleShortVersionString</key>
	<string>0.9.0</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>0.9.0</string>
	<key>IOKitPersonalities</key>
	<dict>
		<key>AppleIntelPanelA</key>
		<dict>
			<key>ApplePanels</key>
			<dict>
				<key>F10T15bb</key>
				<data>
				ABEAAAA2AFQAfQCyAPUBSQGxAisCuANZBBME7AXzBzQI
				rwpq
				</data>
			</dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.driver.AppleBacklight</string>
			<key>IOClass</key>
			<string>AppleIntelPanelA</string>
			<key>IODisplayParameters</key>
			<dict>
				<key>brightness</key>
				<dict>
					<key>max</key>
					<integer>255</integer>
					<key>min</key>
					<integer>40</integer>
				</dict>
				<key>commit</key>
				<dict>
					<key>reg</key>
					<integer>0</integer>
				</dict>
			</dict>
			<key>IOMatchCategory</key>
			<string>IODisplayParameters</string>
			<key>IONameMatch</key>
			<string>backlight</string>
			<key>IOProbeScore</key>
			<integer>2500</integer>
			<key>IOProviderClass</key>
			<string>IOACPIPlatformDevice</string>
		</dict>
	</dict>
	<key>OSBundleRequired</key>
	<string>Safe Boot</string>
</dict>
</plist>
  • Like 1
Link to comment
Share on other sites

Hi, gigabyte666 .

First of all , I wanna thank you from the bottom of my heart :thumbsup_anim: . Because of your hard work , I've been able to run Hackintosh on HP-Envy 15-J0092nr.

I've used your docs and files to run it on my laptop.

I always follows your recent files,docs update, but recently I've done the mach_kernel(XCPM) from rehabman's perl patch and tried to use stock AICPM , I can run it from usb Clover bootloader,
but when I tried to run it from hdd EFI/bootloader , I'm getting KP.(Sort of "IOFamily...") ,
but previously with your XCPM free kernel , I can easily boot from HDD.

I know , you are busy , but If you can , Try to give some ans or upload(update) your recent "Clover files , dsdt,ssdts".

Thanks again man. :)


hi gigabyte666,

 

did you have previously a shutdown issue? i have a laptop, whose power can't be shut off when i shut down the computer. do you have a same problem before? if yes, how did you solve it :P Thanks

Ya , I do have same problem .
Tried to find solutions , but I'm out of luck.

 I always reboot , and shutdown from motherboard power button or windows.

Hope , gigabyte666 can help us.

Link to comment
Share on other sites

My AppleBacklight.kext is vanilla. Try without the injector installed. As I mentioned I never looked at FixEDID, so I'm not really certain what's even in your injector (maybe it does something completely different than mine [which is quite simple]). Use IORegistryExplorer to verify that ACPIBacklight is attached to the PNLF.

 

For reference this is the Info.plist from my AppleBacklightInjector.kext:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleExecutable</key>
	<string>AppleBacklight</string>
	<key>CFBundleGetInfoString</key>
	<string>0.9.0, OpenSource 2014 RehabMan. All rights reserved.</string>
	<key>CFBundleIdentifier</key>
	<string>org.rehabman.driver.AppleBacklightInjector</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>AppleBacklightInjector</string>
	<key>CFBundlePackageType</key>
	<string>KEXT</string>
	<key>CFBundleShortVersionString</key>
	<string>0.9.0</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>0.9.0</string>
	<key>IOKitPersonalities</key>
	<dict>
		<key>AppleIntelPanelA</key>
		<dict>
			<key>ApplePanels</key>
			<dict>
				<key>F10T15bb</key>
				<data>
				ABEAAAA2AFQAfQCyAPUBSQGxAisCuANZBBME7AXzBzQI
				rwpq
				</data>
			</dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.driver.AppleBacklight</string>
			<key>IOClass</key>
			<string>AppleIntelPanelA</string>
			<key>IODisplayParameters</key>
			<dict>
				<key>brightness</key>
				<dict>
					<key>max</key>
					<integer>255</integer>
					<key>min</key>
					<integer>40</integer>
				</dict>
				<key>commit</key>
				<dict>
					<key>reg</key>
					<integer>0</integer>
				</dict>
			</dict>
			<key>IOMatchCategory</key>
			<string>IODisplayParameters</string>
			<key>IONameMatch</key>
			<string>backlight</string>
			<key>IOProbeScore</key>
			<integer>2500</integer>
			<key>IOProviderClass</key>
			<string>IOACPIPlatformDevice</string>
		</dict>
	</dict>
	<key>OSBundleRequired</key>
	<string>Safe Boot</string>
</dict>
</plist>

 

I tested it without the injector already and it made no difference. I plan to make an injector so thank you for the example data. I will try to build my own injector and will update you afterwards.

 

hi gigabyte666,

 

did you have previously a shutdown issue? i have a laptop, whose power can't be shut off when i shut down the computer. do you have a same problem before? if yes, how did you solve it :P Thanks

Nope, this is the first i've heard of the issue. My machine doesn't seem to have an issue shutting down.

 

Hi, gigabyte666 .

 

First of all , I wanna thank you from the bottom of my heart :thumbsup_anim: . Because of your hard work , I've been able to run Hackintosh on HP-Envy 15-J0092nr.

 

I've used your docs and files to run it on my laptop.

 

I always follows your recent files,docs update, but recently I've done the mach_kernel(XCPM) from rehabman's perl patch and tried to use stock AICPM , I can run it from usb Clover bootloader,

but when I tried to run it from hdd EFI/bootloader , I'm getting KP.(Sort of "IOFamily...") ,

but previously with your XCPM free kernel , I can easily boot from HDD.

 

I know , you are busy , but If you can , Try to give some ans or upload(update) your recent "Clover files , dsdt,ssdts".

 

Thanks again man. :)

 

Ya , I do have same problem .

Tried to find solutions , but I'm out of luck.

 

 I always reboot , and shutdown from motherboard power button or windows.

 

Hope , gigabyte666 can help us.

...then why haven't you liked the post yet? ;p

 

In all seriousness though, Have you been properly rebuilding your kernelcaches? If not, you should try booting without caches as a test. Otherwise, your KPs could be from whatever smbios you are using. Updating my files on here won't benefit you much. Since I have switched to using a MacBookPro11,3 smbios, you'd need to be either running the machine-specific build of 10.9.1 or replaced boot.efi, etc in order to use it with Clover. When I get the chance I was already planning to update those files. Don't hold your breath on them fixing your problems though.

 

Note: Updated patches (compared to those in post #261, #262) are available on my patch repo @ https://github.com/RehabMan/Laptop-DSDT-Patch

 

"Brightness fix (HD3000/HD4000)" (for Sandy/Ivy IGPU)

-and-

"Brightness fix (Haswell)" (for Haswell IGPU)

Nice post! Thanks for the repo link. i'll be playing with this over the next few days. :)

Link to comment
Share on other sites

I tested it without the injector already and it made no difference. I plan to make an injector so thank you for the example data. I will try to build my own injector and will update you afterwards.

I noticed a small problem in the patch (for ACPIBacklight) as I was putting things in the repo. Some later added comments were lacking a '\n' at the end causing some real code to get commented out. Corrected in the repo (before it went live) and in the OP in this thread.

 

At any rate, things should work with the patch from the repo. The whole patch can be used even for patched/injected data for AppleBacklight... there is just a lot that doesn't get used in that case. I prefer ACPIBacklight now though...

  • Like 1
Link to comment
Share on other sites

I noticed a small problem in the patch (for ACPIBacklight) as I was putting things in the repo. Some later added comments were lacking a '\n' at the end causing some real code to get commented out. Corrected in the repo (before it went live) and in the OP in this thread.

 

At any rate, things should work with the patch from the repo. The whole patch can be used even for patched/injected data for AppleBacklight... there is just a lot that doesn't get used in that case. I prefer ACPIBacklight now though...

 

I knew I wasn't crazy! I thought I saw some uncommented lines in there somewhere. It's the reason I mentioned it in an earlier post. I wasn't sure though since I couldn't go back to double check at the time.

 

Glad you found and fixed it. I'll try again using the new patch. Thanks for the heads up!

Link to comment
Share on other sites

 Share

×
×
  • Create New...