Jump to content
Dr. Hurt

Refined ALPS TouchPad driver

Recommended Posts

On 3/19/2018 at 10:38 PM, bisk said:

Hey guys, I really appreciate your suggestions but that karabiner App is way overkill for my wanting to just remap 2 key combos. That thread on the other site that Jake Lo suggested was spot on for what I want to achieve but simply doesn't work. Neither my E6540 nor my E6240 will remap anything based on those tips. I don't see how the op made it happen and everybody involved over there has just disappeared.

 

Man, why are we having Fn+F3 and Fn+F15 do brightness- and brightness+ when these functions are meant for the Fn+up and Fn+down arrow keys on so many Latitude Dells ?

 

Everything else maps beautifully !

 

If anyone is still having problems with this the brightness function on the arrow keys of my E6230 works fine by patching the BRT6 method in the DSDT. This looks like it should be applicable to most Latitude models as many use the same brightness control method. Open your DSDT source file in MaciASL, click Patch, paste the code below in the top section and click apply.

 

Spoiler

into method label BRT6 replace_content
begin
    If (LEqual (Arg0, One))\n
    {\n
// Brightness Up\n
        Notify (^^LPCB.PS2K, 0x0366)\n
    }\n
    If (And (Arg0, 0x02))\n
    {\n
// Brightness Down\n
        Notify (^^LPCB.PS2K, 0x0365)\n
    }\n
end;

 

Share this post


Link to post
Share on other sites

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.

 

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...

 

@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...😮

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
On 9/14/2018 at 2:58 AM, Hervé said:

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...

 

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.

Share this post


Link to post
Share on other sites

I am having an issue in regards to "sleep". I have an alps v8 touchpad and using darsch latest v8 kext, but if my laptop goes to sleep on wake the touchpad stops working completely. 

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
14 hours ago, Hervé said:

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.

 

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×