Contribute
Register

remap brightness keys from Fn+Ins, Fn+PgUp to Fn+F8, Fn+F9 with VoodooPS2?

Status
Not open for further replies.
Joined
Aug 3, 2014
Messages
101
Motherboard
Thinkpad T440p
CPU
i7-4710MQ (replaced stock i5)
Graphics
HD4600
Mac
  1. MacBook
  2. MacBook Pro
Classic Mac
  1. Power Mac
  2. PowerBook
Mobile Phone
  1. Android
  2. Other
These are the brightness keys I use in Linux and I want to make them the same for OS X.

Currently Fn+PgUp increases brightness and Fn+Ins decreases in OS X

I tried the Rehabman ACPIDebug Kext + DSDT patch, but nothing appears in the log console when I press Fn+F8 or Fn+F9.

So then I tried the debug version of VoodooPS2. Once again, nothing appears in the log when I press Fn+F8 or Fn+F9.

The only info I can get is from the debug version of VoodooPS2.

When I press Fn+Ins i get ApplePS2Keyboard: sending key 46=6b in the log.

When I press Fn+PgUp I get ApplePS2Keyboard: sending key e045=71.

I think I have to put a line in the VoodooPS2keyboard.kext/Info.plist like:
Code:
<string>XXXX=6b</string>
<string>YYYY=71</string>

but how do I find XXXX and YYYY?
 
These are the brightness keys I use in Linux and I want to make them the same for OS X.

Currently Fn+PgUp increases brightness and Fn+Ins decreases in OS X

I tried the Rehabman ACPIDebug Kext + DSDT patch, but nothing appears in the log console when I press Fn+F8 or Fn+F9.

So then I tried the debug version of VoodooPS2. Once again, nothing appears in the log when I press Fn+F8 or Fn+F9.

The only info I can get is from the debug version of VoodooPS2.

When I press Fn+Ins i get ApplePS2Keyboard: sending key 46=6b in the log.

When I press Fn+PgUp I get ApplePS2Keyboard: sending key e045=71.

I think I have to put a line in the VoodooPS2keyboard.kext/Info.plist like:
Code:
<string>XXXX=6b</string>
<string>YYYY=71</string>

but how do I find XXXX and YYYY?

Which ps2 drivers are you using?

If you have Synaptics trackpad and are using mine here: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller

As far as getting brightness buttons working, first use the debug VoodooPS2Controller to see if they generate PS2 codes or not (probably not). Monitor system.log with Console.app while you press each key. If they generate a ps2 code, see custom keyboard mapping via Info.plist: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller/wiki/How-to-Use-Custom-Keyboard-Mapping

If no ps2 codes in system.log, then they are likely handled via ACPI. See here: https://github.com/RehabMan/OS-X-ACPI-Debug, install the kext, apply "Add DSDT Debug Methods" and "Instrument EC Queries". Look in system.log as you press the key to determine which _Qxx methods handle the keys.

Then patch DSDT:

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, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
end;
into method label _Q11 replace_content
begin
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
end;
 
Doh! I forgot to apply the Instrument EC Queries patch.
That's why I was getting no log of the key presses.

So now I'm confused because the log says Fn+F8 and Fn+F9 call the same EC _Q12 method.
 
Doh! I forgot to apply the Instrument EC Queries patch.
That's why I was getting no log of the key presses.

So now I'm confused because the log says Fn+F8 and Fn+F9 call the same EC _Q12 method.

That can happen... It means the _Q12 method must have some way to disambiguate. Analysis of the code in that method is necessary.
 
That can happen... It means the _Q12 method must have some way to disambiguate. Analysis of the code in that method is necessary.


You already posted an easier solution a while back for another Clevo laptop owner who had both keys invoking Q12. This worked for me:

1. Install VoodooPS2 kext
2. Back up dsdt.dsl before patching
3. Apply the "OS Check Fix" Patch to DSDT
4. Apply "Add DSDT Debug Methods" and "Instrument EC Queries" patches to DSDT.
5. Load ACPIDebug kext and find the QXX methods by pressing the keys and looking in Console app log. (Q11 for Fn+F8 and Q12 for Fn+F9 in my case)
6. Replace the two methods with these methods:

Code:
[COLOR=#4C2F2D][FONT=Courier]Method [/FONT][/COLOR][COLOR=#C02EC0][FONT=Courier]([/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier]_[/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier]Q11[/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier], 0, NotSerialized[/FONT][/COLOR][COLOR=#C02EC0][FONT=Courier])[/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier] 
           {[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]               //Brightness Down[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0205[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0285[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            }[/FONT][/COLOR]

[COLOR=#4C2F2D][FONT=Courier]Method [COLOR=#c02ec0]([/COLOR]_Q12, 0, NotSerialized[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            {[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]                //BrightnessUp[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]                Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0206[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]                Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0286[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            }
[/FONT][/COLOR]


Thanks again!
 
You already posted an easier solution a while back for another Clevo laptop owner who had both keys invoking Q12. This worked for me:

1. Install VoodooPS2 kext
2. Back up dsdt.dsl before patching
3. Apply the "OS Check Fix" Patch to DSDT
4. Apply "Add DSDT Debug Methods" and "Instrument EC Queries" patches to DSDT.
5. Load ACPIDebug kext and find the QXX methods by pressing the keys and looking in Console app log. (Q11 for Fn+F8 and Q12 for Fn+F9 in my case)
6. Replace the two methods with these methods:

Code:
[COLOR=#4C2F2D][FONT=Courier]Method [/FONT][/COLOR][COLOR=#C02EC0][FONT=Courier]([/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier]_[/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier]Q11[/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier], 0, NotSerialized[/FONT][/COLOR][COLOR=#C02EC0][FONT=Courier])[/FONT][/COLOR][COLOR=#4C2F2D][FONT=Courier] 
           {[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]               //Brightness Down[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0205[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0285[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            }[/FONT][/COLOR]

[COLOR=#4C2F2D][FONT=Courier]Method [COLOR=#c02ec0]([/COLOR]_Q12, 0, NotSerialized[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            {[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]                //BrightnessUp[/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]                Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0206[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]                Notify[COLOR=#c02ec0]([/COLOR]\_SB.PCI0.LPCB.PS2K, 0x0286[COLOR=#c02ec0])[/COLOR][/FONT][/COLOR]
[COLOR=#4C2F2D][FONT=Courier]            }
[/FONT][/COLOR]


Thanks again!

Yes, "OS Check Fix" is usually one of those patches you would have applied long before getting to this point. It is one of the patches almost everyone should be applying to their DSDT very early in the process. Almost all DSDTs have conditional code dependent on specific versions of Windows. "Windows 20006" or "Windows 2012" are good versions of Windows to simulate for "Darwin".
 
Yes, "OS Check Fix" is usually one of those patches you would have applied long before getting to this point. It is one of the patches almost everyone should be applying to their DSDT very early in the process. Almost all DSDTs have conditional code dependent on specific versions of Windows. "Windows 20006" or "Windows 2012" are good versions of Windows to simulate for "Darwin".

Are there more, uh , baseline patches? Should I be using more SSDTs?

DSDT and SSDT1..9 were extracted using the linux acpidump.

I am only using DSDT.aml, SSDT from SSDTPRGen.sh and SSDT-4 from Linux acpidump

All I have done is:
"Fix ADBG Error" (DSDT)
"Rename GFX0 to IGPU" (DSDT, SSDT-4 (in linux acpidump parlance))
"Brightness Fix (Haswell)" (SSDT-4)
"OS Check Fix" (DSDT)
manual EC _Q11,_Q12 changes for VoodooPS2 custom keys

About power management...
I think the right stuff is there under CPU0 in IOReg and temps are around 45-55C. But shouldn't there be more than than 7 P-states according to DPCIManager (8, 25, 26, 28, 29, 30 31)?
 
Are there more, uh , baseline patches?

At least some of the patches in section "System Patches" are commonly needed: https://github.com/RehabMan/Laptop-DSDT-Patch.

I usually like to only apply a patch when there is a demonstrated need.

Should I be using more SSDTs?

It depends on the content of the OEM SSDTs.

About power management...
I think the right stuff is there under CPU0 in IOReg and temps are around 45-55C. But shouldn't there be more than than 7 P-states according to DPCIManager (8, 25, 26, 28, 29, 30 31)?

You might observe more with AppleIntelCPUPowerManagementInfo.kext.
 
Which ps2 drivers are you using?

If you have Synaptics trackpad and are using mine here: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller

As far as getting brightness buttons working, first use the debug VoodooPS2Controller to see if they generate PS2 codes or not (probably not). Monitor system.log with Console.app while you press each key. If they generate a ps2 code, see custom keyboard mapping via Info.plist: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller/wiki/How-to-Use-Custom-Keyboard-Mapping

If no ps2 codes in system.log, then they are likely handled via ACPI. See here: https://github.com/RehabMan/OS-X-ACPI-Debug, install the kext, apply "Add DSDT Debug Methods" and "Instrument EC Queries". Look in system.log as you press the key to determine which _Qxx methods handle the keys.

Then patch DSDT:

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, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
end;
into method label _Q11 replace_content
begin
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
end;

Hi Rehabman,
I was working on "Brightness Key mapping" and I realized that this patch worked partially at first.
What I had to do to get the mapping fully functional, was to use _Q11 brightness down, and _Q12 Brightness up.
This is for my HP 250 G5 (Clover 10.13). You see when looked at my Aspire E1 -572 (Clover 10.13) and HP 250-G5 DSDTs they both, DO NOT have "_Q10" EC Methods.

SO now on the HP 250 G5, I can just press the standard F2 and F3 keys only, and get perfect up - down levels, while on the Aspire E1 -572, I have to press shift+F1, shift+F2. Great work btw.
Just a FYI.
 
Hi Rehabman,
I was working on "Brightness Key mapping" and I realized that this patch worked partially at first.
What I had to do to get the mapping fully functional, was to use _Q11 brightness down, and _Q12 Brightness up.
This is for my HP 250 G5 (Clover 10.13). You see when looked at my Aspire E1 -572 (Clover 10.13) and HP 250-G5 DSDTs they both, DO NOT have "_Q10" EC Methods.

SO now on the HP 250 G5, I can just press the standard F2 and F3 keys only, and get perfect up - down levels, while on the Aspire E1 -572, I have to press shift+F1, shift+F2. Great work btw.
Just a FYI.

The EC query methods used vary between different computers.
It is why you use ACPIDebug to determine which methods are connected to the keys.
See guide:
https://www.tonymacx86.com/threads/guide-patching-dsdt-ssdt-for-laptop-backlight-control.152659/
 
Status
Not open for further replies.
Back
Top