Contribute
Register

[Guide] Patching DSDT/SSDT for LAPTOP backlight control

I think examining the system log in Sierra is now complicated enough that a link like that should be including in your guide. That link doesn't say that --stream is the best method to use with log for seeing the key presses or how to filter only messages that are the key presses or that the key presses are reported by "VoodooPS2Keyboard" so that should be in the predicate for filtering.

Anyway, you stated how exactly to use the ioio command instead of telling the user to read the VoodooPS2Controller readme or the ioio readme, so you could do the same for the log command. Actually, the VoodooPS2Controller readme doesn't mention that ioio can be used to log key codes, so maybe this should be added there to the VoodooPS2Controller readme.

If you have some issue, you must provide "Problem Reporting" files as per post #1.
Without them, no help.
I've attached the problem reporting files.
 

Attachments

  • joevt backlight problemreportingfiles.zip
    3.9 MB · Views: 138
I think examining the system log in Sierra is now complicated enough that a link like that should be including in your guide. That link doesn't say that --stream is the best method to use with log for seeing the key presses or how to filter only messages that are the key presses or that the key presses are reported by "VoodooPS2Keyboard" so that should be in the predicate for filtering.

Console.app still works if you're willing to learn how it works...

Anyway, you stated how exactly to use the ioio command instead of telling the user to read the VoodooPS2Controller readme or the ioio readme, so you could do the same for the log command. Actually, the VoodooPS2Controller readme doesn't mention that ioio can be used to log key codes, so maybe this should be added there to the VoodooPS2Controller readme.

I don't think anyone would notice ioio instructions in the VoodooPS2Controller README... hence why it is in this guide.

I've attached the problem reporting files.

Since SSDT-PNLF does not recognize your device-id (it only recognizes supported devices, eg. Arrandale, HD3000 and better)...
It is defaulting to PWMMax of 0x56c (as if it was Skylake/KabyLake).
So, you need to set LMAX as appropriate via SSDT-Config.aml.
You will need to determine what PWMMax your patched AppleIntelSNBGraphicsFB.kext is using. Stock uses 0x710, but you may have changed it.
 
Console.app still works if you're willing to learn how it works...
Can you explain how to make it show the key presses? I can't figure it out.

Since SSDT-PNLF does not recognize your device-id (it only recognizes supported devices, eg. Arrandale, HD3000 and better)...
It is defaulting to PWMMax of 0x56c (as if it was Skylake/KabyLake).
So, you need to set LMAX as appropriate via SSDT-Config.aml.
That doesn't explain why it works after the display has been put to sleep at least once. In either case, when it works or doesn't work, I can see the ApplePanelRawBrightness value change between 0 and 56C in IORegistryExplorer2.1. Even if the max is wrong, the brightness value does change, so the backlight should change accordingly.

The question is, why does the value only get output to hardware when the display has been put to sleep since the last startup? Maybe adding some ACPIDebug stuff will help? Does PNLF._INI get called more than once?

You will need to determine what PWMMax your patched AppleIntelSNBGraphicsFB.kext is using. Stock uses 0x710, but you may have changed it.
I didn't change anything. My AppleIntelSNBGraphicsFB.kext only contains changes to the info.plist. My config.plist does set AAPL,snb-platform-id.

Is there a way to determine PWMMax from Windows 10? I can read PCI registers and get ACPI function results in Windows if that would help.
 
Can you explain how to make it show the key presses? I can't figure it out.

Action->Include Debug Messages
Action->Include Info Messages
You can set 'search' to "ps2"

That doesn't explain why it works after the display has been put to sleep at least once.

Of course it does.
PWMMax is set in the _INI of SSDT-PNLF.aml.
And it is set by the graphics device drivers on wake from sleep.
The two settings must be the same.

I didn't change anything. My AppleIntelSNBGraphicsFB.kext only contains changes to the info.plist. My config.plist does set AAPL,snb-platform-id.

Is there a way to determine PWMMax from Windows 10? I can read PCI registers and get ACPI function results in Windows if that would help.

Stock AppleIntelSNBGraphicsFB.kext always uses PWMMax 0x710.
 
Action->Include Debug Messages
Action->Include Info Messages
You can set 'search' to "ps2"
That works. I had tried that before but I think I forgot to enter the ioio command before looking at Console.app.

Of course it does.
PWMMax is set in the _INI of SSDT-PNLF.aml.
And it is set by the graphics device drivers on wake from sleep.
The two settings must be the same.
I'm still not sure why sleeping the display is required. I added some ACPI debug statements. _INI is only ever called once. Maybe PNLF isn't setting some values correctly because it is using the Skylake method instead of the SandyBridge method. Then maybe sleep sets the values correctly, so then after that, the Apple driver will change the level. I guess I could look at the level values before and after sleep using lspci or something.

Since SSDT-PNLF does not recognize your device-id (it only recognizes supported devices, eg. Arrandale, HD3000 and better)...
It is defaulting to PWMMax of 0x56c (as if it was Skylake/KabyLake).
So, you need to set LMAX as appropriate via SSDT-Config.aml.
Even if I set LMAX, PNLF would still assume it was dealing with a Skylake/KabyLake device, and use the Skylake method for initializing the current level and scale. Also the UID would differ.

Anyway, I was able to fix the problem by adding the missing Sandy Bridge device IDs. Since PNLF reads the device ID from PCI (mine is 0x0106), the Clover FakeID (0x0126) has no affect.
Code:
                    // Sandy
                    0x0102, 0x0106, 0x0116, 0x0126, 0x0112, 0x0122, 0x010A,
                    // Ivy
                    0x0166, 0x016a,
                    // Arrandale
                    0x42, 0x46
So now PNLF will use the SandyBridge method to set the level and max values and the UID is set to the one for SandyBridge.

Stock AppleIntelSNBGraphicsFB.kext always uses PWMMax 0x710.
When _INI is called, the level and max are 0x3d0. Does the Max actually matter? It's used as a scale value, so wouldn't 0x710/0x710 be the same as 0x3d0/0x3d0 or 0x56c/0x56c?
 
I'm still not sure why sleeping the display is required.

Because your SSDT-PNLF is initializing PWMMax incorrectly.

Even if I set LMAX, PNLF would still assume it was dealing with a Skylake/KabyLake device,

No.
Setting LMAX to 0x710 will force to the code to use 0x710 (Sandy Bridge value).
The _UID will follow.
You should read the code.

Bottom line: No changes necessary to SSDT-PNLF. All you need to do is to set RMCF.LMAX correctly.

When _INI is called, the level and max are 0x3d0.

This is the root of the problem and the purpose of SSDT-PNLF _INI code.

Does the Max actually matter?

The max doesn't really matter, if it weren't for the fact that the drivers in macOS assume certain values.
The initialized PWMMax must match those assumptions.
Most PC BIOS does not use values that match the macOS driver assumptions.
 
Because your SSDT-PNLF is initializing PWMMax incorrectly.

No.

Setting LMAX to 0x710 will force to the code to use 0x710 (Sandy Bridge value).
The _UID will follow.
You should read the code.

Bottom line: No changes necessary to SSDT-PNLF. All you need to do is to set RMCF.LMAX correctly.

This is the root of the problem and the purpose of SSDT-PNLF _INI code.

The max doesn't really matter, if it weren't for the fact that the drivers in macOS assume certain values.
The initialized PWMMax must match those assumptions.
Most PC BIOS does not use values that match the macOS driver assumptions.
I removed my Sandy bridge PCI device id (0x106) from PNLF. I added RMCF with LMAX set to 0x710. The UID of PNLF is then 14 (the one for SandyBridge) and ApplePanelRawBrightness changes in IORegistry from 0 to 0x710, but the brightness of the panel will not change unless it has been put to sleep previously.

I believe the problem is because the Skylake method is used in PNLF._INI instead of the SandyBridge method, to initialize the registers when the device ID is not one of the SandyBridge device IDs.

The SandyBridge method is like this:
Code:
               // change/scale only if different than current...
               Local1 = LEVX >> 16
               If (!Local1) { Local1 = Local2 }
               If (Local2 != Local1)
               {
                   // set new backlight PWMMax but retain current backlight level by scaling
                   Local0 = (LEVL * Local2) / Local1
                   //REVIEW: wait for vblank before setting new PWM config
                   //For (Local7 = P0BL, P0BL == Local7, ) { }
                   Local3 = Local2 << 16
                   If (Local2 > Local1)
                   {
                       // PWMMax is getting larger... store new PWMMax first
                       LEVX = Local3
                       LEVL = Local0
                   }
                   Else
                   {
                       // otherwise, store new brightness level, followed by new PWMMax
                       LEVL = Local0
                       LEVX = Local3
                   }
               }
The Skylake method is like this:
Code:
               // This 0xC value comes from looking what OS X initializes this\n
               // register to after display sleep (using ACPIDebug/ACPIPoller)\n
               LEVW = 0xC0000000

               // change/scale only if different than current...
               Local1 = LEVX >> 16
               If (!Local1) { Local1 = Local2 }
               If (Local2 != Local1)
               {
                   // set new backlight PWMAX but retain current backlight level by scaling
                   Local0 = (((LEVX & 0xFFFF) * Local2) / Local1) | (Local2 << 16)
                   //REVIEW: wait for vblank before setting new PWM config
                   //For (Local7 = P0BL, P0BL == Local7, ) { }
                   LEVX = Local0
               }
 
I removed my Sandy bridge PCI device id (0x106) from PNLF. I added RMCF with LMAX set to 0x710. The UID of PNLF is then 14 (the one for SandyBridge) and ApplePanelRawBrightness changes in IORegistry from 0 to 0x710, but the brightness of the panel will not change unless it has been put to sleep previously.

I believe the problem is because the Skylake method is used in PNLF._INI instead of the SandyBridge method, to initialize the registers when the device ID is not one of the SandyBridge device IDs.

The SandyBridge method is like this:
Code:
               // change/scale only if different than current...
               Local1 = LEVX >> 16
               If (!Local1) { Local1 = Local2 }
               If (Local2 != Local1)
               {
                   // set new backlight PWMMax but retain current backlight level by scaling
                   Local0 = (LEVL * Local2) / Local1
                   //REVIEW: wait for vblank before setting new PWM config
                   //For (Local7 = P0BL, P0BL == Local7, ) { }
                   Local3 = Local2 << 16
                   If (Local2 > Local1)
                   {
                       // PWMMax is getting larger... store new PWMMax first
                       LEVX = Local3
                       LEVL = Local0
                   }
                   Else
                   {
                       // otherwise, store new brightness level, followed by new PWMMax
                       LEVL = Local0
                       LEVX = Local3
                   }
               }
The Skylake method is like this:
Code:
               // This 0xC value comes from looking what OS X initializes this\n
               // register to after display sleep (using ACPIDebug/ACPIPoller)\n
               LEVW = 0xC0000000

               // change/scale only if different than current...
               Local1 = LEVX >> 16
               If (!Local1) { Local1 = Local2 }
               If (Local2 != Local1)
               {
                   // set new backlight PWMAX but retain current backlight level by scaling
                   Local0 = (((LEVX & 0xFFFF) * Local2) / Local1) | (Local2 << 16)
                   //REVIEW: wait for vblank before setting new PWM config
                   //For (Local7 = P0BL, P0BL == Local7, ) { }
                   LEVX = Local0
               }

True. There is no mechanism in the current SSDT-PNLF code to control Sandy/Ivy vs. Haswell+ PWM register layout for an unrecognized device-id.

If you were to document the changes in a separate thread (you mentioned AppleIntelSNBGraphicsFB Info.plist changes) required to support QE/CI on your 8086:0106 device, I would consider adding support for 0x0106 directly in the SSDT-PNLF.dsl code.

But for now, as far as I know 8086:0106 will not be fully functional, so I don't feel it needs support in SSDT-PNLF.
 
Hi
IMPORTANT: 10.12.4 and later

Refer to this guide for backlight implementation: https://www.tonymacx86.com/threads/...rol-using-applebacklightinjector-kext.218222/

Note: This guide can still be used on 10.12.4+ to implement your backlight keys...


Overview


Note: This guide is primarily for Intel HD graphics (HD3000->HD5000+, including now Skylake HD 5x0). Although some of the kexts and patches mentioned here can be used in other scenarios, that is not the focus of this post.

By default, your non-Apple DSDT does not have the necessary trigger to cause AppleBacklight.kext to load. Although it is easy to make it load by adding a PNLF device (aka "Brightness Fix" from my laptop repo), it will likely not work correctly. It may not work at all prior to sleep, and even after sleep the full range of brightness will not be available. This is becuase AppleBacklight.kext only has profiles for panels that appear in actual Apple products and there can be PWM registers that are not initialized by BIOS as OS X expects.

A slightly modified DSDT patch can correct for the problem before sleep, and the issue of full range can be fixed by patching AppleBacklight.kext (or providing an injector kext that does the same thing), or by patching EDID. But still, smooth transitions when using keyboard controls will not work (reason not known).

A complete solution to the problem can be achieved with ACPIBacklight.kext and a more complex DSDT patch.

In addition, a second method using the standard PNLF patch ("Brightness Fix") can be used. That method uses a different kext, IntelBacklight.kext instead of ACPIBacklight.kext. That method will be discussed first, followed by ACPIBacklight.kext. ACPIBacklight.kext is a bit more flexible as it can be used in scenarios where IntelBacklight.kext does not work.

In order to implement brightness you must have working graphics drivers (QE/CI), and you must be using a laptop snb-platorm-id/ig-platform-id. Brightness controls are available only for internal LVDS displays.

Note: IntelBacklight.kext + "Brightness Fix" is the preferred solution. IntelBacklight.kext is faster, has been updated for Skylake integrated graphics. There are no plans to update ACPIBacklight.kext for Skylake graphics.


DSDT patching for IntelBacklight.kext

Using normal methods for patching DSDT: http://www.tonymacx86.com/el-capitan-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html

The patches are available here: https://github.com/RehabMan/Laptop-DSDT-Patch

Apply: "Brightness Fix".

Note: "Brightness Fix" can be applied to an SSDT if you wish. Unlike the patches specifically for ACPIBacklight.kext, it does not matter. Apply it to only one file though.

Now install IntelBacklight.kext.

It is available here: https://github.com/RehabMan/OS-X-Intel-Backlight

Reboot and test. If it works, you do not have to worry about ACPIBacklight.kext and the more complex patches. For most laptops with integrated Intel graphics hardware, it will work (in fact, it will work in any computer where the conventional ACPIBacklight.kext method discussed below works).

Do continue to read this thread for information on enabling your backlight keys.


DSDT/SSDT patching for ACPIBacklight.kext

There are two different DSDT patches available. One for pre-Haswell (Arrandale, Sandy Bridge/HD3000, Ivy Bridge/HD4000) and one for Haswell, and Broadwell (HD4400/HD4600/HD5000+, HD5500/HD6000+).

You should follow the general guidelines for DSDT patching as presented here: http://www.tonymacx86.com/yosemite-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html

The patches are available here: https://github.com/RehabMan/Laptop-DSDT-Patch

pre-Haswell: "Brightness Fix (HD3000/HD4000)"
Haswell: "Brightness Fix (Haswell/Broadwell)"

Apply only the brightness patch that applies to your hardware. The patch must be applied to the the file (DSDT or SSDT) where the integrated graphics device is defined. Intel hardware is always at address 0x00020000. Searching for "Name (_ADR, 0x00020000)" is a way to find the device. It is commonly called GFX0, so searching for "Device (GFX0)" is also an effective search most of the time.

The patch will only apply to the file where it finds the device at 0x0002000.

Note: By setting LMAX to Zero, you can cause the patch to use BIOS register values at boot. This can eliminate an extra flash at boot time and may be better for some laptops (the _BCL table is automatically scaled as required).


ACPIBacklight.kext

For complete brightness control including smooth transitions, you need to install ACPIBacklight.kext.

It is available here: https://github.com/RehabMan/OS-X-ACPI-Backlight


IGPU power management

It is common to fix power management for the IGPU at the same time as applying brightness. To implement IGPU PM, apply "Rename GFX0 to IGPU" to DSDT and all patched SSDTs. Failure to apply it universally will likely cause one or more SSDTs to be ignored.

Note: Older versions of the patch required this patch, but newer versions do not have that restriction. IGPU power management is still worthwhile to implement.


Backlight troubleshooting

After installing ACPIBacklight.kext rebooting with the brightness patch in place,you should have an operational brightness slider in SysPrefs->Displays. Keyboard control over backlight is a separate issue.

If your backlight control is not working, it could be due to one or more issues:
- incorrect patch applied
- a previous PNLF patch has been applied to DSDT
- Clover is providing PNLF in DSDT (avoid AddPNLF in ACPI/DSDT/Fixes)
- you forgot to drop OEM SSDTs (Clover: ACPI/SSDT/DropOem=true; Chameleon DropSSDT=Yes)
- renames were not balanced causing OS X to ignore one or more SSDTs
- there are duplicate _DSM methods causing OS X to ignore one or more SSDTs
- your DSDT/SSDTs are out-of-sync with your native DSDT/SSDTs files
- you have not disabled a secondary discrete graphics card in a switched configuration (see guide: http://www.tonymacx86.com/yosemite-...bling-discrete-graphics-dual-gpu-laptops.html)
- your hardware does not use the IGPU PWM backlight controls

To determine if your hardware uses the PWM backlight controls, temporarily remove ACPIBacklight.kext to use AppleBacklight.kext. If the brightness slider in SysPrefs->Displays works (check both before and after display sleep), then your laptop uses the backlight registers and the cause is one of the others mentioned above.

If it does not work, then your laptop doesn't use the backlight registers. In that case, try "Brightness Fix", which will cause ACPIBacklight.kext to use the OEM methods (most of the time, the OEM methods do not work). If your OEM methods actually work (with "Brightness Fix"), you may be able to use "Brightness Fix (ACPI 100)" for smoother transitions and more backlight levels.

It is quite common for ACPIBacklight.kext (and the DSDT patches discussed here) to not work unless you disable the discrete card on switched dual-GPU configurations. Done in BIOS or via DSDT/SSDT patches.


Brightness Keys

The brightness patch will only enable the slider in SysPrefs->Displays. Keyboard control is a separate issue, as the keyboard driver must generate the special codes used to trigger the OS X native backlight controls.

Your brightness keys (usually one of the Fn+F1...F12 keys) may be handled with PS2 or ACPI. Most newer computers use ACPI for these keys. If your trackpad is Synaptics and you're using my fork VoodooPS2Controller.kext (https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller), you can make either case work.

The first step is to determine if they are handled by PS2 or ACPI. With my driver, you can use 'ioio -s ApplePS2Keyboard LogScanCodes 1' to turn on the key logging to system.log. The ioio binary is available here: https://github.com/RehabMan/OS-X-ioio (please read the README for download locations). After turning on key logging, monitor system.log with Console.app to determine what PS2 codes (if any) are generated when you press your keys). If they generate PS2 codes, you can map them to backlight control by following the wiki: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller/wiki/How-to-Use-Custom-Keyboard-Mapping.

If your keys do not generate PS2 codes, it is likely they generate ACPI events. In order to intercept the ACPI events, you will need to determine which method(s) are called when the keys are pressed. Usually, media keys generate EC queries. A simple strategy is to use ACPIDebug.kext to instrument all EC query methods, then press the keys while monitoring system.log. When you press the keys, the name of the method will be output, which will allow you to patch that method.

Note: It is relatively common that the EC will not generate these events unless a certain version of Windows is being emulated by the DSDT. Make sure you patch DSDT as per the linked guide before getting to this. In particular, one of the "OS Check Fix" patches may be necessary before the EC query methods will be called.

Determining EC query methods:

- install ACPIDebug.kext: https://github.com/RehabMan/OS-X-ACPI-Debug
- add the ACPIDebug repo to MaciASL "Sources" per README
- apply ""Add DSDT Debug Methods"
- apply "Instrument EC Queries"
- reboot
- monitor system.log as you press your brightness keys

After you have determined which methods correspond to the brightness keys, you can patch the methods...

Assuming _Q10 is brightness down, and _Q11 is up.
Code:
into method label _Q10 replace_content
begin
// Brightness Down\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0405)\n
end;
into method label _Q11 replace_content
begin
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0406)\n
end;

The 0x0405 corresponds to PS2 keydown/keyup are automatic (e005/e085) for the brightness down key used by Dell laptops. In the default keyboard profile, these correspond to ADB codes 91/90 (brigthness down/up). If your laptop uses a keyboard profile other than the default, you may need to use different codes.

For 10.12+, you might want to generate F14/F15 due to problems with the "real" brightness key codes:
Code:
into method label _Q10 replace_content
begin
// Brightness Down\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0365) //F14\n
end;
into method label _Q11 replace_content
begin
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0366) //F15\n
end;

Note: For 10.12, VoodooPS2Controller.kext (version 1.8.25 or later) has been updated to generate F14/F15 instead of the brightness ADB codes. Make sure you have the latest version installed.

It is possible for both keys (up/down) to generate a call to the same EC query method. This is the case with the Haswell HP Envy, for example. By examining the code it is possible to determine how to disambiguate. As it turns out a variable in the EC is set to indicate the function to be performed when the _Q13 method is invoked. The patch for this case is as follows:

Code:
into method label _Q13 replace_content
begin
Store(HKNO, Local0)\n
If (LEqual(Local0,7))\n
{\n
// Brightness Down\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0405)\n
}\n
If (LEqual(Local0,8))\n
{\n
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0406)\n
}\n
If (LEqual(Local0,4))\n
{\n
// Mirror toggle\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x046e)\n
}\n
end;

Of course, this code is based on the original code in the DSDT for the HP Haswell Envy. It is likely the details for disambiguation in your DSDT differs. You need to read the original code and make the adjustments to the replacement code as necessary.

As another example, some of the recent Dell laptops have a complex path from EC queries (or even a single query method) through NEVT that eventually lands in the BRT6 method. Resulting in the following patch:
Code:
into method label BRT6 replace_content
begin
    If (LEqual (Arg0, One))\n
    {\n
// Brightness Up\n
        Notify (^^LPCB.PS2K, 0x0406)\n
    }\n
    If (And (Arg0, 0x02))\n
    {\n
// Brightness Down\n
        Notify (^^LPCB.PS2K, 0x0405)\n
    }\n
end;

Note: This patch also includes support for the "mirror toggle" function, where the standard PS2 code is 0e6e/0eee (make/break).

Recent laptops are showing even more complex scenarios. Some use GPE methods instead of EC queries (meaning you must instrument GPE methods to determine which one). And some funnel all events through one GPE method typically routing through a single method (typically NEVT). See here for a detailed walkthrough/example: http://www.tonymacx86.com/yosemite-...-laptop-backlight-control-44.html#post1100377

Note: Not all DSDTs use PS2K as the name for the keyboard object. Search for PNP0303 or PNP030B. Also, not all DSDTs use LPCB as the LPC device. Use the actual path your DSDT uses.

Note on certain Dell laptops

Some Dell laptops generate PS2 codes for the brightness keys. There is built-in support for these PS2 codes in my VoodooPS2Controller.kext. But often these keyboards generate 'make' codes without 'break' codes. That is, they generate codes for the keys going down, but no code for the key being released. This causes the key to infinitely repeat.

The VoodooPS2Keyboard.kext driver has a mechanism to fix this called "Breakless PS2". And there is a built-in Dell profile that has the correct "Breakless PS2" setttings. But you have to select the profile with an SSDT.

The SSDT is checked into the VoodooPS2 project as SSDT-DELL-WN09.dsl: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller

To use it, save as AML, and place in ACPI/patched so it can be loaded by Clover. If you're using SortedOrder, make sure it refers to the file you place in ACPI/patched.


Note on ELAN (and other) drivers

If you are using another keyboard driver, instead of sending notifications to the PS2 object, you can send them to an object attached to ACPIKeyboard.kext The process is very similar to the process as written above (for ACPI), and is covered well at the ACPIKeyboard github README. See here: https://github.com/RehabMan/OS-X-ACPI-Keyboard

Some newer versions of the ELAN driver may have direct support with codes 0x10 and 0x20. So, no need for ACPIKeyboard.kext in this case.

See below for an example:
Code:
into method label _Q28 replace_content
begin
// Brightness Down\n
    Notify (PS2K, 0x20)\n
end;
into method label _Q30 replace_content
begin
// Brightness Up\n
    Notify (PS2K, 0x10)\n
end;


Providing Feedback

Do not treat this thread as your private troubleshooting thread. If you have a specific problem with your specific laptop, open a separate thread. If you see something here that is in error, or wish to make a contribution, please reply to this thread.


Problem Reporting

Download patchmatic: https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-patchmatic-2015-0107.zip
Extract the 'patchmatic' binary from the ZIP. Copy it to /usr/bin, such that you have the binary at /usr/bin/patchmatic.

In terminal,
Code:
if [ -d ~/Downloads/RehabMan ]; then rm -R ~/Downloads/RehabMan; fi
mkdir ~/Downloads/RehabMan
cd ~/Downloads/RehabMan
patchmatic -extract

Note: It is easier if you use copy/paste instead of typing the commands manually.

Post contents of Downloads/RehabMan directory (as ZIP).

Also, post ioreg: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

And output from:
Code:
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc

Also, post EFI/Clover folder (press F4 at main Clover screen before collecting). Please eliminate 'themes' directory, especially if you have an overabundance of themes installed.

Also post output of:
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /

@RehabMan,

Trying to remap the keyboard keys for Brightness.

Using ioio -s ApplePS2Keyboard LogScanCodes 1 does not generate any PS2 codes in the console log.

So I figured to use ACPIDebug.kext method.

I copied ACPIDebug.kext to Extension folder and ensured that it is loaded under System\Extensions (See Library - Extensions.zip)

I have extract DSDT file using clover and command :
iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml. (See DSDT.dsl.zip)

I'm using maciASL with ACPI 6.1 .

Added the repo as a MaciASL "source" in MaciASL preferences

Selected the "Add DSDT Debug method"

The challenge is that patch command generate an error "Name already exits in scope (BNUM) "

I know this has nothing related to your patch, and it seems that the dsl file we generate of clover has an issue.

How do I resolve this ?
 

Attachments

  • Error.png
    Error.png
    578.1 KB · Views: 141
  • EFI.zip
    1.7 MB · Views: 94
  • Library - Extensions.zip
    2 MB · Views: 75
  • DSDT.dsl.zip
    53.3 KB · Views: 83
Hi


@RehabMan,

Trying to remap the keyboard keys for Brightness.

Using ioio -s ApplePS2Keyboard LogScanCodes 1 does not generate any PS2 codes in the console log.

So I figured to use ACPIDebug.kext method.

I copied ACPIDebug.kext to Extension folder and ensured that it is loaded under System\Extensions (See Library - Extensions.zip)

I have extract DSDT file using clover and command :
iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml. (See DSDT.dsl.zip)

I'm using maciASL with ACPI 6.1 .

Added the repo as a MaciASL "source" in MaciASL preferences

Selected the "Add DSDT Debug method"

The challenge is that patch command generate an error "Name already exits in scope (BNUM) "

I know this has nothing related to your patch, and it seems that the dsl file we generate of clover has an issue.

How do I resolve this ?

Comment or delete the 'External(BNUM,...' line.
 
Back
Top