PS/2 Keyboard Scan Codes no longer working in macOS 11+

[vuxuanhungg]

Hi, I followed your guide to enable keyboard scan codes. I tried both methods, but Console.app does not show any relevant information when pressing any key.

From Rehabman's guide:

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.

I don't know if I miss anything for such a simple thing to work. I'm using OpenCore release version, and I've disabled all OpenCore debugging options in config.plist if that matters.

• ioio: I grabbed it from here and put into usr/local/bin
  

• VoodooPS2Keyboard's Info.plist:
  

• Console:
  

system.log" seems to be static, as it does not show any keyboard event either.

[5T33Z0]

I have the same problem. I tried method 2. Could be that the keys are mapped via EC or that it doesn't work and more in general.

See:

• [VoodooPS2] I can't scan keycodes of Fn shortcuts for (Fn + F8...) acidanthera/bugtracker#872
• 07-PS2键盘映射及亮度快捷键，执行“ioio -s ApplePS2Keyboard LogScanCodes 1”提示：“No service matching "ApplePS2Keyboard"” daliansky/OC-little#46

For now, the only thing I can do is add a note to the guide.

You could try ACPI Debugging to find and map the keys via SSDT. Here's an example for Lenovo Thinkpads:

https://github.com/5T33Z0/OC-Little-Translated/blob/main/05_Laptop-specific_Patches/Fixing_Keyboard_Mappings_and_Brightness_Keys/Customizing_ThinkPad_Keyboard_Shortcuts.md

You only have to adapt it to your machine.

[vuxuanhungg]

Regarding ACPI Debugging, it's the actual thing I want to get into. But I read the Rehabman guide and I think I need to get PS2 scan codes logging into Console first. If the driver itself does not log, I don't think I can get ACPIDebug log the EC queries into Console (which is determined by pressing a key handled by the driver).

Maybe I'll try with some older version to see if it's working or not.

Two (arbitrary) keys to adjust brightness by default on Dell laptops by Voodoo is Fn+S/B. I found that pressing those keys is more responsive than Fn+F11/F12 (the "actual" keys). This can be easily seen when press and hold or quickly press the keys to adjust up or down. Fn+S/B is smoother while for Fn+F11/F12, there seems to be a delay in each step. That's why I want to get into debugging these keys to see how Fn+S/B adjust the brightness that seems to differ from Fn+F11/F12.

---

I've just schemed through your linked post, and it's a lot to digest =)). However, it seems that Dell laptops are different from Thinkpad in the aspect that I don't see many _Qxx methods in my DSDT. Actually, mine only shows _Q66.

Regarding the function keys remapping to adjust brightness, the trick here works for me. You can see that on Dell laptops, there are BRT6 method to adjust brightness, instead of _Qxx.

Several things that intrigues me are:

From the above post, there are several key codes to adjust brightness.

brightness increase: key codes 0x10, 0x206, 0x286, 0x366, 0x0406
brightness decrease: key codes 0x20, 0x205, 0x285, 0x365, 0x0405

Your post mentions 0x3- and 0x4- prefixes, what's about 0x2- prefix in this case?

Also, a little off topic, but except for 0x10 and 0x20, I have tried all the rest and all of them works (some trigger one level, or brightness "dot" at a time, some trigger two dots at a time). Today, I even realized that, without adding SSDT-BRT6.aml and the corresponding rename BRT6,2 to BRTX,2, Fn+F11/F12 triggers brightness adjustment just fine by themselves.

It seems that VoodooPS2 already handled those keys, they are just not triggered without SSDT-XOSI.

[5T33Z0]

I can't tell you much about custom key mapping becaause I only have ThinkPads and they work without additional keymappings because both BrightnessKeys.kext and YogaSMC.kext can handle these.

For Dell Laptops, there's an easy fix in the Dell Section: https://github.com/5T33Z0/OC-Little-Translated/tree/main/05_Laptop-specific_Patches/Brand-specific_Patches/Dell_Special_Patch#ssdt-ocwork-dell

[vuxuanhungg]

I couldn't think setting a fixed value for ACSE and ACOS could be that simple. Why don't people use this but mess up with SSDT-XOSI and binary rename =))?

[vuxuanhungg]

Regarding ACPI debug, there are no logs to Console just as I expected. I'll try some older version.

[5T33Z0]

I couldn't think setting a fixed value for ACSE and ACOS could be that simple. Why don't people use this but mess up with SSDT-XOSI and binary rename =))?

Well, not everybody understands how preset variables can work in their favor.

This way, I recently figured out a super simple and elegant IRQ fix to disable HPET on older ThinkPads via preset variabled so that audio works. Previous fixes used all kind of acrobatics to do this. My fix doesn't need a single binary rename and is fully acpi-compliant :D

[vuxuanhungg]

I can confirm that logging key codes in Mojave works (latest VoodooPS2 kexts)

[5T33Z0]

Can you test it in Catalina as well? Maybe logging only works in 32 bit. That would exclude Catalina as well.

[vuxuanhungg]

Catalina works as well. Monterey doesn't. I won't intend to test BigSur though =))

[5T33Z0]

Thanks for verifying. I've tested Big Sur myself. Not working. I guess it's because of the switch from kexts to Kernel Collections introduced with Big Sur