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

If i'm understanding this correctly, what you're saying is that this patch should apply properly to my dsdt? Is this correct?

Yes. It covers all _Qxx methods in your DSDT.

 

As I expected but sadly, it doesn't explain why pairing fails. I can only assume it's because the Voodoo prefpane takes the place of the pane used by the trackpad. It paired properly and took maybe a full minute to pair on my tower but the laptop has a difficult time of even locating the device. Pairing slowed the machine to a crawl and just fails every time. Hmm...

VoodooPS2 pref pane has nothing to do with BT pairing. In addition, I don't provide a prefpane in my builds.

Link to comment
Share on other sites

Yes. It covers all _Qxx methods in your DSDT.

Ok, thank you for clarifying. I will test soon and post results.

VoodooPS2 pref pane has nothing to do with BT pairing. In addition, I don't provide a prefpane in my builds.

Poor wording on my part. Apologizes. I understand that you don't provide prefpanes with your versions. What I mean is the configuration pane for my trackpad is set as the same pane that the Magic Trackpad would normally use, which is the default "Trackpad" pref pane. I think it's causing interference with the apple trackpad setup process. I'll just have to try it again and see if I can figure out the problem.

Link to comment
Share on other sites

...

Poor wording on my part. Apologizes. I understand that you don't provide prefpanes with your versions. What I mean is the configuration pane for my trackpad is set as the same pane that the Magic Trackpad would normally use, which is the default "Trackpad" pref pane. I think it's causing interference with the apple trackpad setup process. I'll just have to try it again and see if I can figure out the problem.

Never heard of that one -- if something like that is happening, it is Apple's bug... People have a lot of trouble with BT, but if you have a good/compatible BT chip (best is one that is inside actual Apple laptops), BT is much more reliable. Key is having a well supported not-so-buggy BT chip. Personally, I don't use BT as I just don't need it.

 

Pairing is done in the BT prefpane, isn't it?

Link to comment
Share on other sites

Never heard of that one -- if something like that is happening, it is Apple's bug... People have a lot of trouble with BT, but if you have a good/compatible BT chip (best is one that is inside actual Apple laptops), BT is much more reliable. Key is having a well supported not-so-buggy BT chip. Personally, I don't use BT as I just don't need it.

 

Pairing is done in the BT prefpane, isn't it?

Unbelievable! Figures...I just tried it again and this time everything went smooth as butter. I have no clue why it decided to work this time but failed horribly the first few times I tried. Disregard everything I just said about this since i'm clearly just crazy or something. How irritating. lol >_>

 

UPDATE: I can clarify that the Voodoo trackpad config pane does NOT agree with the Magic Trackpad's pref pane. They both clearly use different methods of implementing the same features into the devices. I found that enabling single-tap on the apple trackpad will disable it on the internal trackpad and vice-versa. Many options work this way. So if options are changed for one, they must be disabled/reenabled if they are to be used again for the previous device before they will work again. kind of annoying but at least they both work now. Figured I would document this while it's fresh in my mind. Too bad there isn't a way to enable all the nifty gestures from the apple trackpad into your voodoo kext, RehabMan. ;p

Link to comment
Share on other sites

...

Too bad there isn't a way to enable all the nifty gestures from the apple trackpad into your voodoo kext, RahabMan. ;p

Yeah, the hardware isn't up to it. Not enough bandwidth on the PS2 interface to do well with multitouch.

Link to comment
Share on other sites

Yeah, the hardware isn't up to it. Not enough bandwidth on the PS2 interface to do well with multitouch.

Well, that's disappointing. That's ok though since the internal trackpad support is really as good as it needs to be anyway.

 

I have news though. I tested out the EC patch and here are the results for my keys. What do you make of them?

f2 [brightness down]:
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff81010d3ecc)
ACPIDebug: "H_EC._Q13 enter"
ACPIDebug: "H_EC._Q13 exit"
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff81010d3ecc)

f3 [brightness up]:
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff80f9523ecc)
ACPIDebug: "H_EC._Q13 enter"
ACPIDebug: "H_EC._Q13 exit"
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff80f9523ecc)

There are some differences between them as you can no doubt see but having them both register as one key certainly seems to have been spot on. Can anything be done with these results and your new VoodooPS2?

Link to comment
Share on other sites

Well, that's disappointing. That's ok though since the internal trackpad support is really as good as it needs to be anyway.

 

I have news though. I tested out the EC patch and here are the results for my keys. What do you make of them?

f2 [brightness down]:
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff81010d3ecc)
ACPIDebug: "H_EC._Q13 enter"
ACPIDebug: "H_EC._Q13 exit"
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff81010d3ecc)

f3 [brightness up]:
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff80f9523ecc)
ACPIDebug: "H_EC._Q13 enter"
ACPIDebug: "H_EC._Q13 exit"
ACPIDebug::message(-536707056, 0xffffff8023086b00, 0xffffff80f9523ecc)
There are some differences between them as you can no doubt see but having them both register as one key certainly seems to have been spot on. Can anything be done with these results and your new VoodooPS2?

 

OK, so same method is called when either key is hit.

 

Looking at original DSDT code, you can see that the value of HKNO (hot-key-number?) determines what is done with the notification (three possibilities: 4, 7, and 8):

                    Method (_Q13, 0, Serialized)  // _Qxx: EC Query
                    {
                        Name (T_0, Zero)
                        While (One)
                        {
                            Store (HKNO, T_0) /* \_SB_.PCI0.LPCB.H_EC._Q13.T_0_ */
                            If (LEqual (T_0, 0x04))
                            {
                                Notify (IGPU, 0x80) // Status Change
                            }
                            Else
                            {
                                If (LEqual (T_0, 0x07))
                                {
                                    Notify (^^^IGPU.DD1F, 0x87) // Device-Specific
                                }
                                Else
                                {
                                    If (LEqual (T_0, 0x08))
                                    {
                                        Notify (^^^IGPU.DD1F, 0x86) // Device-Specific
                                    }
                                }
                            }

                            Break
                        }
                    }
So we now want to know what is the value of HKNO with each of your keys... Hopefully it comes out different for each bright up/down...

 

into method label _Q13 parent_label H_EC code_regex ([\s\S]*) replace_matched
begin
\\rmdt.p1("H_EC._Q13 enter")\n
\\rmdt.p2("H_EC._Q13: HKNO is", HKNO)\n
%1\n
\\rmdt.p1("H_EC._Q13 exit")\n
end;
I suspect it will be 7 and 8 for your up and down, but we need to know which one is associated with which key.
Link to comment
Share on other sites

OK, so same method is called when either key is hit.

 

Looking at original DSDT code, you can see that the value of HKNO (hot-key-number?) determines what is done with the notification (three possibilities: 4, 7, and 8):

                    Method (_Q13, 0, Serialized)  // _Qxx: EC Query
                    {
                        Name (T_0, Zero)
                        While (One)
                        {
                            Store (HKNO, T_0) /* \_SB_.PCI0.LPCB.H_EC._Q13.T_0_ */
                            If (LEqual (T_0, 0x04))
                            {
                                Notify (IGPU, 0x80) // Status Change
                            }
                            Else
                            {
                                If (LEqual (T_0, 0x07))
                                {
                                    Notify (^^^IGPU.DD1F, 0x87) // Device-Specific
                                }
                                Else
                                {
                                    If (LEqual (T_0, 0x08))
                                    {
                                        Notify (^^^IGPU.DD1F, 0x86) // Device-Specific
                                    }
                                }
                            }

                            Break
                        }
                    }
So we now want to know what is the value of HKNO with each of your keys... Hopefully it comes out different for each bright up/down...

 

into method label _Q13 parent_label H_EC code_regex ([\s\S]*) replace_matched
begin
\\rmdt.p1("H_EC._Q13 enter")\n
\\rmdt.p2("H_EC._Q13: HKNO is", HKNO)\n
%1\n
\\rmdt.p1("H_EC._Q13 exit")\n
end;
I suspect it will be 7 and 8 for your up and down, but we need to know which one is associated with which key.

 

Ok, so I assume I can apply the new patch right over the same test dsdt or should I go back a bit and start without EC edits?

 

Afterwards, am I simply rechecking my system.log with ACPIDebug?

 

UPDATE: Nevermind. Pretty sure I got this. This what we were looking for? :D

f2:
ACPIDebug: { "H_EC._Q13: HKNO is", 0x7, }

f3:
ACPIDebug: { "H_EC._Q13: HKNO is", 0x8, }

For completeness sake, I also found which HKNO the 4 was associated with:

f4 [display switch HDMI/interal?]:
ACPIDebug: { "H_EC._Q13: HKNO is", 0x4, }
Link to comment
Share on other sites

Ok, so I assume I can apply the new patch right over the same test dsdt or should I go back a bit and start without EC edits?

 

Afterwards, am I simply rechecking my system.log with ACPIDebug?

 

UPDATE: Nevermind. Pretty sure I got this. This what we were looking for?

f2:
ACPIDebug: { "H_EC._Q13: HKNO is", 0x7, }

f3:
ACPIDebug: { "H_EC._Q13: HKNO is", 0x8, }

 

Yes, and so now we turn it into a patch that will convert these events to ps2 packets...

 

into method label _Q13 parent_label H_EC replace_content
begin
Store(HKNO, Local0)\n
If (LEqual(Local0,7))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
}\n
If (LEqual(Local0,8))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
}\n
end;
This code sends the Dell PS2 codes (via ACPI Notify) for brightness down/up when the two EC events are detected, which are converted to 0x91/0x90 ADB codes when received by the ps2 keyboard driver.

 

This is a new feature of my VoodooPS2 (v1.8.11), so make sure you're using the latest build or one built from source.

 

Please note when you're pressing F2/F3, that these are actually Fn+F2/Fn+F3 to the keyboard controller+driver as your BIOS settings are such that the normal function of Fn+fkeys and fkeys are reversed.

  • Like 2
Link to comment
Share on other sites

Yes, and so now we turn it into a patch that will convert these events to ps2 packets...

 

into method label _Q13 parent_label H_EC replace_content
begin
Store(HKNO, Local0)\n
If (LEqual(Local0,7))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
}\n
If (LEqual(Local0,8))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
}\n
end;
This code sends the Dell PS2 codes (via ACPI Notify) for brightness down/up when the two EC events are detected, which are converted to 0x91/0x90 ADB codes when received by the ps2 keyboard driver.

 

This is a new feature of my VoodooPS2 (v1.8.11), so make sure you're using the latest build or one built from source.

 

Please note when you're pressing F2/F3, that these are actually Fn+F2/Fn+F3 to the keyboard controller+driver as your BIOS settings are such that the normal function of Fn+fkeys and fkeys are reversed.

 

Nice! Yup, I already had your new driver downloaded, I was waiting around to use it since I wasn't sure if I would have to make modifications to it like I had to for the version I was previously using. Which brings me to my next question. Do I need to edit the kext at all before installing it and giving it a go? While waiting for a reply from you I decided to peek at the new options listed under the Info.plist and i'm noticing you added quite a bit to it.

 

You've explained the BIOS fn swap before but I suppose i'm still a bit confused by the concept since according to my BIOS settings, my f2/f3 setup should be normal and shouldn't require fn to activate those keys. I imagine it's probably an OS X thing in that it reads the info backwards or something since I would never enable the fn key requirement in order to active those keys, lol.

Link to comment
Share on other sites

Nice! Yup, I already had your new driver downloaded, I was waiting around to use it since I wasn't sure if I would have to make modifications to it like I had to for the version I was previously using. Which brings me to my next question. Do I need to edit the kext at all before installing it and giving it a go? While waiting for a reply from you I decided to peek at the new options listed under the Info.plist and i'm noticing you added quite a bit to it.

No need to edit the kext. e005/e006 are already mapped to the correct ADB codes.

 

Yes, I implemented a few more features to help with my Lenovo u430 keyboard. In particular, macro inversion. Several of the special Fn+fkey keys generate multiple keys to trigger certain functions in Windows. Like Alt+F4, or Ctrl+Alt+P. The scan codes come in rapidly... faster than a human can type them, so I'm able to detect these macros and translate back into a single key.

Link to comment
Share on other sites

No need to edit the kext. e005/e006 are already mapped to the correct ADB codes.

 

Yes, I implemented a few more features to help with my Lenovo u430 keyboard. In particular, macro inversion. Several of the special Fn+fkey keys generate multiple keys to trigger certain functions in Windows. Like Alt+F4, or Ctrl+Alt+P. The scan codes come in rapidly... faster than a human can type them, so I'm able to detect these macros and translate back into a single key.

Ok, thank you. Testing in progress...

 

UPDATE: *whew* It worked! Gotta be honest, i never expected getting the brightness keys to function properly would have turned into such a chore. Well, I gotta hand it to you RehabMan, you know your s***. :D

 

Thanks for popping in to help me with this one. ^_^

 

Here's a set of patches for instrumentation. It includes instrumentation checking for completion of _PTS/_WAK just in case you're curious about that too.

Now, although sadly it'll have to wait until another day, how exactly can I use this method to check for _PTS/_WAK completion as you mentioned previously? Could that possibly fix my machine's inability to use ACPIBacklight over AppleBacklight? Is the process the same with ACPIDebug?

Link to comment
Share on other sites

Ok, thank you. Testing in progress...

 

UPDATE: *whew* It worked! Gotta be honest, i never expected getting the brightness keys to function properly would have turned into such a chore. Well, I gotta hand it to you RehabMan, you know your s***. :D

 

Thanks for popping in to help me with this one. ^_^

Cool... glad it worked... I wanted to figure that one out when I had the laptop but just ran out of time...

 

Now, although sadly it'll have to wait until another day, how exactly can I use this method to check for _PTS/_WAK completion as you mentioned previously? Could that possibly fix my machine's inability to use ACPIBacklight over AppleBacklight? Is the process the same with ACPIDebug?

Just put the laptop through a sleep/wake cycle, then verify that you get both _WAK/_PTS enter/exit.

 

AS far as ACPIBacklight, I think it is something with the way you're combining SSDTs and DSDT,etc. If you'll send me your complete set of OEM DSDT/SSDTs (new dump from Linux or Clover F4) and your current complete set of patched DSDT/SSDTs, I'll see what I can do with them using my automated repo process...

 

For completeness sake, I also found which HKNO the 4 was associated with:

f4 [display switch HDMI/interal?]:
ACPIDebug: { "H_EC._Q13: HKNO is", 0x4, }

 

You might want to map that key to mirror on/off... You could modify the code to send 0x026e:

into method label _Q13 parent_label H_EC replace_content
begin
Store(HKNO, Local0)\n
If (LEqual(Local0,7))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
}\n
If (LEqual(Local0,8))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
}\n
If (LEqual(Local0,4))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x026e)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x02ee)\n
}\n
end;
PS2 code e06e is mapped to ADB for mirror 0x70.
Link to comment
Share on other sites

Cool... glad it worked... I wanted to figure that one out when I had the laptop but just ran out of time...

Very. Understandable. I will always have more stuff to do than I ever have time for it seems, lol. Thanks again for the help, that was an...interesting task. :)

Just put the laptop through a sleep/wake cycle, then verify that you get both _WAK/_PTS enter/exit.

Oh ok. As always, appreciate the clarification.

AS far as ACPIBacklight, I think it is something with the way you're combining SSDTs and DSDT,etc. If you'll send me your complete set of OEM DSDT/SSDTs (new dump from Linux or Clover F4) and your current complete set of patched DSDT/SSDTs, I'll see what I can do with them using my automated repo process...

Hell, if you think you might be able to figure it out, then be my guest. As much as I didn't really want to, I felt I needed to give up on ACPIBacklight because it was becoming an obsession and I was losing too much sleep over trying to get it working. Provided in the zip are all of the clean files (dsdt+5 ssdts) plus my currently used files (dsdt+2 ssdts). Hopefully, you won't have too much trouble with the edited ones since I recently remade them and cleaned all the garbage I had in my previous batch. 17t-j000_fullset.zip

You might want to map that key to mirror on/off... You could modify the code to send 0x026e:

into method label _Q13 parent_label H_EC replace_content
begin
Store(HKNO, Local0)\n
If (LEqual(Local0,7))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
}\n
If (LEqual(Local0,8))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
}\n
If (LEqual(Local0,4))\n
{\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x026e)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x02ee)\n
}\n
end;
PS2 code e06e is mapped to ADB for mirror 0x70.

 

Cool! Thanks for that. I'll certainly add that into my current setup and use it since I frequently switch between my TV and laptop display, so that should prove handy. Just out of curiosity, would it be possible to make that key turn off the laptop backlight instead for a TV-only experience or would that be too much you think? Still, the mirroring implementation sounds awesome! :D
Link to comment
Share on other sites

Hell, if you think you might be able to figure it out, then be my guest. As much as I didn't really want to, I felt I needed to give up on ACPIBacklight because it was becoming an obsession and I was losing too much sleep over trying to get it working. Provided in the zip are all of the clean files (dsdt+5 ssdts) plus my currently used files (dsdt+2 ssdts). Hopefully, you won't have too much trouble with the edited ones since I recently remade them and cleaned all the garbage I had in my previous batch. attachicon.gif17t-j000_fullset.zip

Looking at diffs right now. Can you provide a few more things:

- fresh full ACPI dump using Clover F4 (result is in EFI/CLOVER/ACPI/origin)

- your current config.plist

 

P.S. Nice cleanup. These patched files look much cleaner than the last ones I looked at. It is possible ACPIBacklight.kext might "just work." There is no PNLF in the current ones, which is why I suspect something in config.plist proving your PNLF currently...

 

Cool! Thanks for that. I'll certainly add that into my current setup and use it since I frequently switch between my TV and laptop display, so that should prove handy. Just out of curiosity, would it be possible to make that key turn off the laptop backlight instead for a TV-only experience or would that be too much you think? Still, the mirroring implementation sounds awesome! :D

My Lenovo u430 has laptop display on/off toggle Fn key. I use it using a similar technique (on/off is then handled in DSDT). I have a request to add a general feature into the ps2 driver: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller/issues/20. Maybe someday I'll get to it.

Link to comment
Share on other sites

Looking at diffs right now. Can you provide a few more things:

- fresh full ACPI dump using Clover F4 (result is in EFI/CLOVER/ACPI/origin)

- your current config.plist

Sure thing, here you go: 17t-j000_CloverF4Dump_config.plist.zip

P.S. Nice cleanup. These patched files look much cleaner than the last ones I looked at. It is possible ACPIBacklight.kext might "just work." There is no PNLF in the current ones, which is why I suspect something in config.plist proving your PNLF currently...

Why thank you good sir. I'm glad you approve of the changes. I pretty much mirrored my setup from my new tower to match this machine as closely as I possibly could. So, much of the updates and changes came from that little side project, which is what I did after I stopped exclusively working on this one. Heh, yeah, I planned to update the first page pretty soon with these files. It's horribly outdated (since my tower project took over my life, lol) so I guess this can be an early release to those who get to snag it before I can find some time to update the main page. :)

 

I can already tell you why my backlight works without PNLF. I'm using the InjectEDID flag in my config.plist. Clover is in charge of handling the backlight for this machine now. It has been ever since I found out that I didn't actually need my old injector.

My Lenovo u430 has laptop display on/off toggle Fn key. I use it using a similar technique (on/off is then handled in DSDT). I have a request to add a general feature into the ps2 driver: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller/issues/20. Maybe someday I'll get to it.

Really? Now that sounds pretty darn cool to me. Wish mine had a dedicated key like that. :(

 

Quick question about your VoodooPS2Controller. Is there anyway to increase the tracking speed beyond what is displayed in the pref pane? I don't typically use my internal trackpad that often but when I have to, I find it is still significantly slower than i'd like, even with the tracking speed set to the max on the slider. On that same note, is it possible to remove the lag between tap-dragging? I don't have drag lock enabled but i feel like the length of time permitted to continue dragging is more than I need, can this be changed as well? Thanks.

 

gygabyte666

 

Hlw , How r you ?

 

Have you tested the new BIOS version F.53 ? If so ,is there anything not working ?

Yes, I am currently running F.53 and I can say that based on my usage, everything seems to still work normally.

  • Like 1
Link to comment
Share on other sites

Hi, I'm curious about HD4600 HDMI patching in your config.plist, will it fix HDMI freeze? Is it on another thread?

 

Thank you.

I am unaware of any HDMI freezes. Mine has never frozen up. Perhaps it is related to audio, if that's the case then you should look into patching the FB/HDA. That info can be found in the first post.

Link to comment
Share on other sites

Thanks, I'll look over it and report back.

 

I can already tell you why my backlight works without PNLF. I'm using the InjectEDID flag in my config.plist. Clover is in charge of handling the backlight for this machine now. It has been ever since I found out that I didn't actually need my old injector.

Really? Now that sounds pretty darn cool to me. Wish mine had a dedicated key like that. :(

I don't think InjectEDID will help with PNLF injection. You're probably using DSDT "fix" AddPNLF_1000000. Or you're using a (buggy) Clover that always injects that fix (PNLF) when it detects mobile. At any rate, you'll need to disable that (injection of PNLF via Clover) if you want to attempt ACPIBacklight again. Clover will inject in DSDT and defeat any PNLF placed in an SSDT. If you look at your DSDT after booting OS X with Clover (just run MaciASL), I think you'll find the PNLF injection in there...

 

Edit: I see looking at your config.plist posted above that you don't have AddPNLF_1000000. This leads to more questions. What version of Clover? And can you post ioreg (please use IORegistryExplorer v2.1). Thanks!

 

Quick question about your VoodooPS2Controller. Is there anyway to increase the tracking speed beyond what is displayed in the pref pane? I don't typically use my internal trackpad that often but when I have to, I find it is still significantly slower than i'd like, even with the tracking speed set to the max on the slider.

A few things for you to try/look at:

- you might try increasing the BogusDeltaThreshX/BogusDeltaThreshY values

- you can decrease the value of Resolution (smaller values for Resolution will speed up the pointer, larger values will slow it down)

 

I still have it on my list to calibrate the behavior so it matches my MacBookAir6,2.

 

On that same note, is it possible to remove the lag between tap-dragging? I don't have drag lock enabled but i feel like the length of time permitted to continue dragging is more than I need, can this be changed as well? Thanks.

Much information can be gathered by reading the changelog. Look at DragExitDelayTime in the Info.plist. It can be set to zero to completely disable this or reduced to make the time shorter. Default is one second which matches as close as I could guess from using my actual Apple MacBook Air.

  • Like 1
Link to comment
Share on other sites

Thanks, I'll look over it and report back.

There are significant differences between the dump you did just now from Clover and the files on which your patched versions are based. Time to do a fresh patch using current native DSDT/SSDT as obviously the base files have changed.

 

There are many changes, but the ones that are particularly important is the fact that the OperationRegion addresses for various SystemMemory declarations are different, including SANV, which is IGPU related.

 

diff of OperationRegion/DSDT:

Speedy-ML:17t-j000_fullset Admin$ diff origin/dsdt.dsl clean/dsdt.dsl|grep OperationRegion
<     OperationRegion (GNVS, SystemMemory, 0x9CF7DA98, 0x000002F6)
>     OperationRegion (GNVS, SystemMemory, 0x92F7DA98, 0x000002EF)
<     OperationRegion (OGNS, SystemMemory, 0x9CF7B018, 0x00001369)
>     OperationRegion (OGNS, SystemMemory, 0x92F7B018, 0x00001355)
<                 OperationRegion (RP_X, SystemMemory, Local0, 0x20)
<                     OperationRegion (RP_X, SystemMemory, Local1, 0x20)
<             OperationRegion (PXVD, SystemMemory, Local0, 0x08)
>         OperationRegion (CMS1, SystemIO, 0x70, 0x02)
<             OperationRegion (MMMM, SystemMemory, Local0, 0x1A)
<             OperationRegion (PXVD, SystemMemory, Local0, 0x04)
<             OperationRegion (PXVD, SystemMemory, Local0, 0x04)
<             OperationRegion (MMMM, SystemMemory, Local0, 0x1A)
<             OperationRegion (XPRT, PCI_Config, Zero, 0x0100)
<             OperationRegion (XHCP, SystemMemory, Add (PEBS, 0x000A0000), 0x0100)
<                 OperationRegion (MCA1, SystemMemory, SRMB, 0x9000)
<                 OperationRegion (MCA1, SystemMemory, SRMB, 0x9000)
>             OperationRegion (XPRT, PCI_Config, Zero, 0x0100)
<     OperationRegion (MDBG, SystemMemory, 0x9CF78018, 0x00001004)
>     OperationRegion (MDBG, SystemMemory, 0x92F78018, 0x00001004)
diff OperationRegion/IGPU SSDT:

Speedy-ML:17t-j000_fullset Admin$ diff origin/SSDT-7.dsl clean/ssdt-1.dsl|grep OperationRegion
<     OperationRegion (SANV, SystemMemory, 0x9CF76D98, 0x0141)
>     OperationRegion (SANV, SystemMemory, 0x92F76D98, 0x013F)
>             OperationRegion (PEGR, PCI_Config, 0xC0, 0x30)
<             OperationRegion (RPCS, SystemMemory, \XBAS, 0x00018040)
<                     OperationRegion (RPCY, SystemMemory, BBAR, 0x25)
>                     OperationRegion (RPCY, SystemMemory, Local0, 0x25)
<                         OperationRegion (IPCV, SystemMemory, BBAR, 0x70)
>                         OperationRegion (IPCV, SystemMemory, Local0, 0x70)
<                     OperationRegion (IPCV, SystemMemory, BBAR, 0xBF)
<                     OperationRegion (IPCV, SystemMemory, BBAR, 0x70)
>                     OperationRegion (IPCV, SystemMemory, Local0, 0x70)
<             OperationRegion (IGDD, SystemMemory, ASLB, 0x2000)
This probably has something to do with ACPIBacklight not working for you :-)

 

New Clover feature, FixRegions_10000000, can help:

Some OperationRegions in Bios DSDT are floating and values may change in time due to changes in the BIOS. The presence of floating regions makes it impossible to use a custom DSDT because this region may be shifted and will not correspond to the current state. This patch is intended to find all such regions in BIOS and correct them in custom DSDT.

Using the patched DSDT/SSDTs you have is like using files from another computer...

Link to comment
Share on other sites

Edit: I see looking at your config.plist posted above that you don't have AddPNLF_1000000. This leads to more questions. What version of Clover? And can you post ioreg (please use IORegistryExplorer v2.1). Thanks!

Clover = r2652

As for the ioreg dump, I will get that to you a bit later as I am unable to access the machine right this moment.

 

I may need to check for Clover auto-applying PNLF because I was unaware that could be happening. That could very well be a major factor for the ACPIBacklight failures. :(

 

A few things for you to try/look at:

- you might try increasing the BogusDeltaThreshX/BogusDeltaThreshY values

- you can decrease the value of Resolution (smaller values for Resolution will speed up the pointer, larger values will slow it down)

 

I still have it on my list to calibrate the behavior so it matches my MacBookAir6,2.

 

 

Much information can be gathered by reading the changelog. Look at DragExitDelayTime in the Info.plist. It can be set to zero to completely disable this or reduced to make the time shorter. Default is one second which matches as close as I could guess from using my actual Apple MacBook Air.

Very nice. Thanks for the info. :D

 

There are significant differences between the dump you did just now from Clover and the files on which your patched versions are based. Time to do a fresh patch using current native DSDT/SSDT as obviously the base files have changed.

 

This probably has something to do with ACPIBacklight not working for you :-)

 

New Clover feature, FixRegions_10000000, can help

 

Using the patched DSDT/SSDTs you have is like using files from another computer...

I see. Guess i'll have to look into this. Suppose that makes sense considering the machine has undergone 2-3 BIOS updates since then and i'm still using files dumped during stock BIOS use. Damn, I knew I should have put together patches so updating would be easier. I'd hate to have to go through redoing everything again. Wouldn't have made much difference I suppose, since I suck so hard at writing patches, lol.
Link to comment
Share on other sites

Clover = r2652

As for the ioreg dump, I will get that to you a bit later as I am unable to access the machine right this moment.

OK no worries. r2652 is new enough to not have the forced PNLF bug, so... I'd like to see ioreg as to how PNLF is being injected. I suspect you're not actually using the patched files you posted... That's just a guess though.

 

I see. Guess i'll have to look into this. Suppose that makes sense considering the machine has undergone 2-3 BIOS updates since then and i'm still using files dumped during stock BIOS use. Damn, I knew I should have put together patches so updating would be easier. I'd hate to have to go through redoing everything again. Wouldn't have made much difference I suppose, since I suck so hard at writing patches, lol.

Yes, definitely will need to repatch. Any BIOS upgrade/memory upgrade/other hardware change (eg. changing WiFi card), can affect these regions. I've even seen some BIOS settings affect it. And I think it explains why all that effort to dump the various registers for IGPU during all that ACPIBacklight debugging effort was always returning garbage.

 

The Clover option is a good one to handle this and make re-patching less necessary, less often (although it only fixes one aspect... OperationRegions, not other changes). Note that the FixRegions feature is new and I have not personally tested it. Slice says it works...

 

Check out my envy15 patch repo, if you want to see one way to automate the process of patching. You'd have to tweak it a bit for your files, but if you have even a little bit of experience with make (or can learn), you should be able to deal with it.

Link to comment
Share on other sites

OK no worries. r2652 is new enough to not have the forced PNLF bug, so... I'd like to see ioreg as to how PNLF is being injected. I suspect you're not actually using the patched files you posted... That's just a guess though.

Well , that's good. Bugs are bad after all. I'm a bit confused. What do you mean? Everything I have sent to you recently is my currently used files (obviously, aside from the clean stuff). If you are referring to the files on the thread's first page then yeah, i'm not really using that anymore since it's all horribly outdated. That was going to be updated ASAP but considering this new information of the current dsdt/ssdts being outdated themselves, I guess that will have to be fixed first.

 

Yes, definitely will need to repatch. Any BIOS upgrade/memory upgrade/other hardware change (eg. changing WiFi card), can affect these regions. I've even seen some BIOS settings affect it. And I think it explains why all that effort to dump the various registers for IGPU during all that ACPIBacklight debugging effort was always returning garbage.

Agreed. If that is the issue then it needs to get fixed. Guess we'll see. I suspect you're correct though as I knew hardware changes affect those files but I was unaware that BIOS updates could affect them so drastically. I ignorantly assumed it could only change it in insignificant, minor ways.

 

The Clover option is a good one to handle this and make re-patching less necessary, less often (although it only fixes one aspect... OperationRegions, not other changes). Note that the FixRegions feature is new and I have not personally tested it. Slice says it works...

So, wait, would using FixRegions be a possible, temporary fix for possible ACPIBacklight testing do you think? I trust Slice's advice. Afterall, he knows Clover pretty well i'd say ;p

 

Check out my envy15 patch repo, if you want to see one way to automate the process of patching. You'd have to tweak it a bit for your files, but if you have even a little bit of experience with make (or can learn), you should be able to deal with it.

Will do. Although, couldn't I just essentially create one giant patch and add/remove to it as needed? I just don't follow the language that the patches use, which is why I can't write my own.
Link to comment
Share on other sites

Well , that's good. Bugs are bad after all. I'm a bit confused. What do you mean? Everything I have sent to you recently is my currently used files (obviously, aside from the clean stuff).

We'll see what's going on when you send ioreg. Ioreg always shows reality.

 

Agreed. If that is the issue then it needs to get fixed. Guess we'll see. I suspect you're correct though as I knew hardware changes affect those files but I was unaware that BIOS updates could affect them so drastically. I ignorantly assumed it could only change it in insignificant, minor ways.

BIOS upgrades sometimes affect ACPI bits in insignificant minor ways. But sometimes they affect ACPI in significant major ways. I always do a diff between disassembled ACPI between BIOS versions so I know what is changed and whether a re-patch is strictly necessary. If re-patch is automated, it is very easy to deal with...

 

So, wait, would using FixRegions be a possible, temporary fix for possible ACPIBacklight testing do you think? I trust Slice's advice. Afterall, he knows Clover pretty well i'd say ;p

Something you could try. You'd be testing the feature in a scenario where it would be useful. Easy to see if all the regions are updated as ACPI files can be extracted from ioreg and compared with native extracts.

 

Will do. Although, couldn't I just essentially create one giant patch and add/remove to it as needed? I just don't follow the language that the patches use, which is why I can't write my own.

Which language are you not understanding? MaciASL/DSDTEditor patches? You would need to use that language to patch no matter how many files you decide to place it in. If you look at my repo, most of the patches I use are not custom patches, but rather patches from my generic laptop repo.

Link to comment
Share on other sites

 Share

×
×
  • Create New...