Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Help] PS/2 Keyboard Scan Codes no longer working in macOS 11+ #92

Open
xuanhung1509 opened this issue Dec 8, 2023 · 11 comments
Open
Labels
documentation Improvements or additions to documentation help wanted Extra attention is needed

Comments

@xuanhung1509
Copy link
Contributor

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
    Screen Shot 2023-12-08 at 9 48 02 AM

  • VoodooPS2Keyboard's Info.plist:
    Screen Shot 2023-12-08 at 11 36 39 AM

  • Console:
    Screen Shot 2023-12-08 at 9 51 22 AM

system.log" seems to be static, as it does not show any keyboard event either.
Screen Shot 2023-12-08 at 11 38 55 AM

@5T33Z0
Copy link
Owner

5T33Z0 commented Dec 8, 2023

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:

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.

@xuanhung1509
Copy link
Contributor Author

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
Copy link
Owner

5T33Z0 commented Dec 8, 2023

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

@xuanhung1509
Copy link
Contributor Author

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 =))?

@xuanhung1509
Copy link
Contributor Author

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

@5T33Z0
Copy link
Owner

5T33Z0 commented Dec 8, 2023

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

@xuanhung1509
Copy link
Contributor Author

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

@5T33Z0
Copy link
Owner

5T33Z0 commented Dec 10, 2023

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

@xuanhung1509
Copy link
Contributor Author

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

@5T33Z0
Copy link
Owner

5T33Z0 commented Dec 10, 2023 via email

@5T33Z0 5T33Z0 changed the title [Help] Cannot enable keyboard scan codes logging [Help] PS/2 Keyboard Scan Codes no longer working in macOS 11+ Dec 10, 2023
@5T33Z0 5T33Z0 reopened this Dec 10, 2023
@5T33Z0 5T33Z0 added documentation Improvements or additions to documentation help wanted Extra attention is needed labels Dec 10, 2023
@5T33Z0
Copy link
Owner

5T33Z0 commented Dec 10, 2023

Reopened the issue and added labels in hope that someone can provide an alternative solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants