Jump to content

Refined ALPS TouchPad driver


Dr. Hurt

Recommended Posts

On 9/11/2018 at 2:22 AM, Hervé said:

Usually, one needs to identify the ACPI Embedded Controller sequence associated with the key strokes or the PS2 values returned by the key strokes (See Rehabman's repo on the matter). Your patch does not do any of that as far as I can see.

 

Hi @Hervé, as you point out above I actually went through the process of instrumenting and tracing the ACPI Methods involved when I originally configured my laptop. I followed Rehabman's guides on his repo and elsewhere on the web.

 

On 9/11/2018 at 2:22 AM, Hervé said:

Nevertheless, I've just tried it and I don't see any difference with it. Fn-UP/Fn-DOWN still only control brightness at hardware/LCD level, not at macOS level. This was already the case before I applied your patch and Fn-F3/Fn-Insert remain the only 2 x key strokes that control brightness at macOS level.

 

As far as I'm concerned, the above patch is either not effective or incomplete. In addition, this patch cannot be applied "as is" to the BRT6 method defined under the dGPU device, only that of the iGPU...

 

From the info I still have the exact sequence is (Q66 - NEVT - SMIE - SMEE - EV5 - BRT6) which only applies to the method under IGPU. For the sequence to reach BRT6 the OS Check Fix for "Darwin" has to be applied to the appropriate _OSI checks under both Method _INI and Method OSID otherwise the firmware will take control of brightness. 

 

On 9/11/2018 at 2:22 AM, Hervé said:

@jpz4085, you should probably post your DSDT and explain what you derived your patch from or how you came to it. Because it seems you send values to the keyboard as opposed to detect key strokes and trigger brightness actions accordingly...😮

 

The VoodooPS2Controller.kext driver has a feature originally implemented by Rehabman that can receive hex codes through ACPI and translate to PS2/ADB codes and associated functions. You can find more about it by searching the patch codes. I would have responded sooner but I had to dump the ACPI tables and go through the patching process to create a DSDT. I've been using Rehabman's hotpatch/SSDT method for over a year and didn't have one. Have a look at the attached files and see if they work for you.

E6230_DSDT.zip

  • Thanks 1
Link to comment
Share on other sites

  • Administrators

Ok, I understand better now. Indeed with the additional Darwin checks under _SB->OSID method, the patch is effective on the E6230. I only had the Darwin check under _SB.PCI0->_INI method which is required for USB3 recognition. Adding the Darwin checks to _SB->OSID does the trick! 👍

 

Well done, thanks for that detailed and very useful contribution. 👏

 

I'll try it on my E6220 and E6440 but I guess the Fn-UP/Fn-DOWN key strokes may return different values that I'll have to identify.

 

NB: I noticed a 4th Darwin check under _SB->PCI0_> _OSC method in the DSDT you posted. It seems to be USB3 (XHC) related but can you explain what this actually does or is meant to do? Here, it kills the 2 x USB ports on the right side after wake so I'm keeping that check out...

Link to comment
Share on other sites

The one under _OSC was added by "OS Check Fix Windows 8" from the MaciASL Patch repo. I needed a Windows 8 patch for my wifi to work and that was where it put it. It appears I don't need that one as it's probably just USB3 specific and my wifi works fine with the one under OSID. Also all my USB ports work both before and after sleep with or without it so it's probably unnecessary.

Link to comment
Share on other sites

Hi @Hervé and @jpz4085, I was hoping one of may help me in regards to getting my brightness keys mapped properly on my Dell E5430. I see that jpz4085 recently posted the following....

"From the info I still have the exact sequence is (Q66 - NEVT - SMIE - SMEE - EV5 - BRT6) which only applies to the method under IGPU. For the sequence to reach BRT6 the OS Check Fix for "Darwin" has to be applied to the appropriate _OSI checks under both Method _INI and Method OSID otherwise the firmware will take control of brightness."

Would one of you perhaps be so kind as to take a look at my debug and see what else I would need to do, as I've already applied the BRT6 patch to my DSDT and have a OS Check Fix in place via an additional SSDT in my patched folder but I'm guessing that it doesn't extend to Method _INI etc mentioned above.

I'm also using the same VoodooPS2Controller kext that jpz4085 included in his zip file (as I was previously using the R6 version) - I've had to do some other key remapping via Karabiner-Elements when using this kext but it would be nice to have the Fn + Up / Down keys to solely control brightness with the HUD showing, rather than having two versions of brightness control (Fn + F3 and Fn + Insert with the HUD and Fn + Up / Down without the HUD).

Any advice would be appreciated as I'm struggling to nail this final piece of the jigsaw.

debug_14446.zip

Link to comment
Share on other sites

  • Administrators

I guess that the key codes probably differ from one laptop to another. You'd need to apply Rehabman's debugging patch in order to identify the codes returned by Fn-UP/Fn-DOWN keystrokes and amend jpz4085's BRT6 patch accordingly. Not done it yet on my E6220/E6440 to verify.

Link to comment
Share on other sites

Hi Hervé,

 

Yeah I've already been trying to use Rehabman's ACPIDebug to establish the codes, but I can't get much further than establishing the start point (_Q66) in the chain but it doesn't reach BRT6 so when I saw jpz4085's post about needing to apply the OS Check Fix to the appropriate _OSI checks I was thinking that perhaps that's the reason why I can't establish the key codes in the sys log, but with my limited knowledge that's where I've got stuck.

 

No worries if you can't advise any further, just thought I'd ask in case you might be able to nudge me in the right direction.

Link to comment
Share on other sites

Hi @Amoxitine it's jpz4085 here,

 

After reviewing your debug files I have made the following corrections. Your model’s DSDT is very similar to mine.

 

I added the “Darwin” check under Method OSID you were missing. (Required for native brightness control.)

I removed Device GFX0 and renamed Device VID (and references) to IGPU. That’s the correct one.

I renamed Device ECDV to EC (and references) so USB power properties will load. (Not required but good to have.)

I removed the XOSI hotpatches and SSDT as it’s unnecessary with the “Darwin” entries in the DSDT.

I removed Intel graphics injection and audio layout ID from your config.plist as that’s already taken care of in your DSDT.

 

Also you can remove the AppleHDA kext patches from your config.plist if you’re only using AppleALC.kext.

I’ve included the source files for the native and patched DSDT for you to customize further if needed.

Copy the attached files under EFI to the correct locations on your EFI partition and see how it works for you.

Dell_E5430.zip

Link to comment
Share on other sites

Hi @jpz4085,

Thank you so much for taking the time out to take a look at my config, wasn't expecting that so I'm very grateful. I have tried your updates, but unfortunately it's now behaving like this...

1) Constantly going into sleep state after 20-30 seconds where I have to either keep pressing Fn + Up, then Fn + Insert, then Fn + Up quickly each time the display goes to black to wake it up.

2) Fn + F3 and Fn + Insert no longer control brightness (but still shows the HUD, only Fn + Up and Down only control the brightness without the HUD).

If I let it go into a sleep state and then wake it up, which takes about 30-60 seconds to wake (or reboot if it doesn't wake) then the repetitive sleep issue goes away and behaves more like it should (plus it returns brightness control back to Fn + F3 and Insert) until I reboot again and then it comes back.

I don't know whether this might be to do with me reverting back to using the VoodooPS2Controller-R6.kext since I did my last debug that you looked at (as I found this had better mapping for the Dell's keyboard compared to another Voodoo kext I found that works with my Alps V3 touchpad) and then applying your updates after that?

Not sure if it helps but I did do another debug which is my most stable config to date called debug_no_sleep_issue (which was just prior to applying your updates) which I think might be a touch different to the one you looked at (but I could be wrong) plus a debug of how things are at the mo.

 

If you have any further suggestions etc I would be very grateful  

 

debug_no_sleep_issue.zip

debug_latest_with_updates.zip

Link to comment
Share on other sites

I have a few suggestions to make. Remove WhateverGreen.kext as this might conflict with the IGPU patches and also remove CodecCommander.kext which shouldn’t be needed with AppleALC.kext. Remove ACPIDebug.kext until you will be instrumenting/tracing ACPI methods if needed.

 

Put back my VoodooPS2Controller.kext, DSDT.aml and config.plist then rebuild the kextcache with sudo kextcache -i / and reboot. Check the Displays in the System Preferences and make sure the brightness slider is present and working. Then try the brightness keys.

 

Other things to try if sleep/brightness issues continue include changing the Darwin patches in Method _INI and OSID to Windows 2009/WIN7 and opening config.plist in Clover Configurator going to Boot and set darkwake=no and restart and see what happens.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...