Contribute
Register

macOS 10.13 Hackintosh on HP OMEN ce003na

Status
Not open for further replies.
RehabMan said:
No need to patch any SSDTs.
Do all renames with config.plist so you avoid patching SSDTs.
(it just makes for extra work when looking for problems when you have patched SSDTs that you don't need).

Injection of backlight properties can be done with an add-on SSDT, or even config.plist/Devices/AddProperties (or Devices/Arbitrary).
Click to expand...

How can I patch the SSDTs from Clover? I'm adding code, not just renaming stuff.
 
RehabMan said:
To add _DSM methods, no need to patch anything... (other than normal rename _DSM->XDSM patch).
See examples in ACPI hotpatch guide:
http://www.tonymacx86.com/threads/guide-using-clover-to-hotpatch-acpi.200137/
Click to expand...

So instead of statically renaming the _DSM Method to XDSM and inserting this below, I can enable the rename _DSM to XDSM patch in Clover and then somehow add the method inside of Clover (which even after reading I don't get how to do)?

You can see the result I need in the attached file (see _DSM).

And instead of adding the Brightness Fix patch in MaciASL can I use AddPNLF in Clover?
 

Attachments

  • SSDT-7.aml
    14.4 KB · Views: 166
Last edited:
xjacx said:
So instead of statically renaming the _DSM Method to XDSM and inserting this below, I can enable the rename _DSM to XDSM patch in Clover and then somehow add the method inside of Clover (which even after reading I don't get how to do)?
Click to expand...

_DSM methods can be added with add-on SSDTs in ACPI/patched.

And instead of adding the Brightness Fix patch in MaciASL can I use AddPNLF in Clover?
Click to expand...

Not in your case. The reasons are subtle but important.

Warning: The following discussion requires a bit of understanding of ACPI.

You DSDT has code that already refers to an existing PNLF identifier. The access to it is not scope qualified (if you search your native DSDT for PNLF, you will see the method). If you add a PNLF at _SB scope, the code that was originally referring to the existing PNLF (in root scope), will instead be referring to _SB.PNLF. You can see how "Brightness Fix" patch patches for this situation (pay attention to the preview window contents).

You could hotpatch the method referring to root scope PNLF. Eg. hotpatch the method at _SB.PCI0.RP15 that reads this way:
Code: 
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (LTRF, LTRZ)
            Store (PMLF, LMSL)
            Store (PNLF, LNSL)
            Store (OBFF, OBFZ)
        }

Such that it qualifies the PNLF access properly... like this:
Code: 
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (LTRF, LTRZ)
            Store (PMLF, LMSL)
            Store (\PNLF, LNSL)
            Store (OBFF, OBFZ)
        }

The "rename/replace" pattern is what you would use, which is covered in the ACPI hotpatch guide.

Alternately, you could place the Device(PNLF) at a path that is not reachable (with unqualified access) from _SB.PCI0.RP15.
For example, you could probably place it at _SB.PCI0.PEG0.PEGP:
Code: 
Device(_SB.PCI0.PEG0.PEGP.PNLF)
{
...
}

That way when the code at _SB.PCI0.RP15._INI executes, the access it has to PNLF will refer to the root PNLF, instead of an invalid access to _SB.PNLF (if you used AddPNLF).
 
RehabMan said:
_DSM methods can be added with add-on SSDTs in ACPI/patched.



Not in your case. The reasons are subtle but important.

Warning: The following discussion requires a bit of understanding of ACPI.

You DSDT has code that already refers to an existing PNLF identifier. The access to it is not scope qualified (if you search your native DSDT for PNLF, you will see the method). If you add a PNLF at _SB scope, the code that was originally referring to the existing PNLF (in root scope), will instead be referring to _SB.PNLF. You can see how "Brightness Fix" patch patches for this situation (pay attention to the preview window contents).

You could hotpatch the method referring to root scope PNLF. Eg. hotpatch the method at _SB.PCI0.RP15 that reads this way:
Code: 
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (LTRF, LTRZ)
            Store (PMLF, LMSL)
            Store (PNLF, LNSL)
            Store (OBFF, OBFZ)
        }

Such that it qualifies the PNLF access properly... like this:
Code: 
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (LTRF, LTRZ)
            Store (PMLF, LMSL)
            Store (\PNLF, LNSL)
            Store (OBFF, OBFZ)
        }

The "rename/replace" pattern is what you would use, which is covered in the ACPI hotpatch guide.

Alternately, you could place the Device(PNLF) at a path that is not reachable (with unqualified access) from _SB.PCI0.RP15.
For example, you could probably place it at _SB.PCI0.PEG0.PEGP:
Code: 
Device(_SB.PCI0.PEG0.PEGP.PNLF)
{
...
}

That way when the code at _SB.PCI0.RP15._INI executes, the access it has to PNLF will refer to the root PNLF, instead of an invalid access to _SB.PNLF (if you used AddPNLF).
Click to expand...

Nice, thanks for taking the time to explain that!

Sometimes the battery works, but most of the time it doesn't. It worked on last boot but this boot it's stopped. Any ideas how I could fix this?
 

Attachments

  • Problem Reporting Files.zip
    2.6 MB · Views: 41
xjacx said:
Nice, thanks for taking the time to explain that!

Sometimes the battery works, but most of the time it doesn't. It worked on last boot but this boot it's stopped. Any ideas how I could fix this?
Click to expand...

Your ioreg shows battery status working. You must separate the idea of "battery status working/not working" (which is an ioreg content thing) vs. battery status not on the menu bar (which is a system UI component issue, usually broken due to startup timing).

Note: Your SSDT-7.aml is completely wrong. It seems it shares nothing in common with SSDT-7.aml in ACPI/origin. No idea what you are trying to accomplish there...

If by "it's stopped" you mean that it has disappeared from the system menu bar, and you have to unplug ac/plug it back/then visit SysPrefs->Energy saver to restore the status to the menu bar, then it likely is due to slow boot (booting from HDD spinner?)...

In which case adjust abm_firstpolldelay until you find a value that works consistently.

It is also a good idea to boot from a fast device, such as SSD instead of HDD.
 
RehabMan said:
Your ioreg shows battery status working. You must separate the idea of "battery status working/not working" (which is an ioreg content thing) vs. battery status not on the menu bar (which is a system UI component issue, usually broken due to startup timing).
Click to expand...

By broken I mean it shows 0% in Sys Prefs and won't add to menu bar.

RehabMan said:
Note: Your SSDT-7.aml is completely wrong. It seems it shares nothing in common with SSDT-7.aml in ACPI/origin. No idea what you are trying to accomplish there...
Click to expand...

Was patched by onejay09. Will delete and create an SSDT with the _DSM patch for backlight in - do I literally just create a new .aml file and then paste in the patch?

RehabMan said:
If by "it's stopped" you mean that it has disappeared from the system menu bar, and you have to unplug ac/plug it back/then visit SysPrefs->Energy saver to restore the status to the menu bar, then it likely is due to slow boot (booting from HDD spinner?)...
Click to expand...

Yeah, doesn't appear in Energy saver though.

RehabMan said:
In which case adjust abm_firstpolldelay until you find a value that works consistently.
Click to expand...

Will do.

RehabMan said:
It is also a good idea to boot from a fast device, such as SSD instead of HDD.
Click to expand...

I would if my SSD was larger. Unfortunately, 256 GB is not big enough to share Windows and macOS on a gaming laptop.
 
xjacx said:
By broken I mean it shows 0% in Sys Prefs and won't add to menu bar.
Click to expand...

Even if you pull the AC adapter, then plug it back in?

Was patched by onejay09. Will delete and create an SSDT with the _DSM patch for backlight in - do I literally just create a new .aml file and then paste in the patch?
Click to expand...

For details on creating SSDTs with _DSM methods refer to the examples in the hotpatch guide.

Yeah, doesn't appear in Energy saver though.
Click to expand...

What doesn't appear?

I would if my SSD was larger. Unfortunately, 256 GB is not big enough to share Windows and macOS on a gaming laptop.
Click to expand...

A larger SSD is probably in your future. Or a second SATA SSD connected where you currently have the HDD...
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top