New VoodooPS2Controller, Keyboard, Trackpad (ClickPad support)

[RehabMan]

Hello, RehabMan:
I come from China, English is not good, I have a few questions for you.
My laptop is thinkpad l430, I used to drive your voodoops2controller.kext trackpad and red spots, and as you install how to wiki to install, the situation now there is a touch panel and a red dot can be used, but preferences can not be found in the touchpad, I want to automatically insert the mouse trackpad shield, how do I do it?
Request your help, thank you!

Which trackpad is in your laptop?

 

[Chocoholic]

I think something broke in the last few versions of this kext...

Using a Dell N5110 with an ALPS v5, I now get:

02/16/2014 22:51:47.000 kernel[0]: VoodooPS2TouchPad Version 1.9.0 loaded...
02/16/2014 22:51:47.000 kernel[0]: VoodooPS2Trackpad: Identify TouchPad command returned incorrect byte 2 (of 3): 0x00
02/16/2014 22:51:47.000 kernel[0]: VoodooPS2TouchPad Version 1.9.0 loaded...


02/16/2014 22:51:47.000 kernel[0]: ApplePS2Controller: Timed out on mouse input stream.
02/16/2014 22:51:47.000 kernel[0]: ApplePS2ALPSGlidePoint::identify: Found ALPS Device with ID E7=0x73 0x03 0x50, EC=0x73 0x01 0x0d
02/16/2014 22:51:47.000 kernel[0]: VoodooPS2Mouse Version 1.8.9 loaded...
02/16/2014 22:51:47.000 kernel[0]: Initializing TouchPad hardware...this may take a second.
02/16/2014 22:51:47.000 kernel[0]: Touchpad initialization complete.

 

[RehabMan]

I think something broke in the last few versions of this kext...

Using a Dell N5110 with an ALPS v5, I now get:

02/16/2014 22:51:47.000 kernel[0]: VoodooPS2TouchPad Version 1.9.0 loaded...
02/16/2014 22:51:47.000 kernel[0]: VoodooPS2Trackpad: Identify TouchPad command returned incorrect byte 2 (of 3): 0x00
02/16/2014 22:51:47.000 kernel[0]: VoodooPS2TouchPad Version 1.9.0 loaded...


02/16/2014 22:51:47.000 kernel[0]: ApplePS2Controller: Timed out on mouse input stream.
02/16/2014 22:51:47.000 kernel[0]: ApplePS2ALPSGlidePoint::identify: Found ALPS Device with ID E7=0x73 0x03 0x50, EC=0x73 0x01 0x0d
02/16/2014 22:51:47.000 kernel[0]: VoodooPS2Mouse Version 1.8.9 loaded...
02/16/2014 22:51:47.000 kernel[0]: Initializing TouchPad hardware...this may take a second.
02/16/2014 22:51:47.000 kernel[0]: Touchpad initialization complete.

Maybe this commit: https://github.com/RehabMan/OS-X-Vo...mmit/2f9cee2bebe8333e50fccae6bf3c6e21dd45d180. Pull was from here: https://bitbucket.org/sontrg/os-x-voodoo-ps2-controller. Perhaps you can report it to the patch author.

Don't know... I don't support/maintain the ALPS version.

You have a weird mix of versions there, so you might want to review your installation procedures.

 

[Chocoholic]

Maybe this commit: https://github.com/RehabMan/OS-X-Vo...mmit/2f9cee2bebe8333e50fccae6bf3c6e21dd45d180. Pull was from here: https://bitbucket.org/sontrg/os-x-voodoo-ps2-controller. Perhaps you can report it to the patch author.

Don't know... I don't support/maintain the ALPS version.

You have a weird mix of versions there, so you might want to review your installation procedures.

You're probably right. Just checked the ALPS thread on OSX Latitude and turns out I'm not the only one having the problem.

sontrg (Son Vu) has fixed the problem and will probably commit the fix soon.

Thanks RehabMan

 

[danild]

Hi RehabMan,

I think I've found a little bug in the latest version of VoodooPS2Controller, not sure it's reproducible in any system, though. The issue is - when I do double-tap dragging (albeit dragging objects, or selecting text) it works as if drag lock were always on, no matter if the checkbox is checked in the Trackpad preferences or not.

Thanks!

 

[RehabMan]

Hi RehabMan,

I think I've found a little bug in the latest version of VoodooPS2Controller, not sure it's reproducible in any system, though. The issue is - when I do double-tap dragging (albeit dragging objects, or selecting text) it works as if drag lock were always on, no matter if the checkbox is checked in the Trackpad preferences or not.

Thanks!

By design.

There is a one second "automatic draglock" just like on a real Mac. Tap to release or wait one second.

 

[danild]

By design.

There is a one second "automatic draglock" just like on a real Mac. Tap to release or wait one second.

Just checked - of course you're right, the one second pause works like a charm.

Many thanks!

 

[TimeWalker]

New VoodooPS2Controller, Keyboard, Trackpad

Hey, @RehabMan,
Currently using IOWMIFamily (see readme on git for details) to process WMI notifications coming from two EC queries that control display brightness. These WMI codes are the same as normal PS2 scancodes would be 0xE005 and 0xE006 for Dell, but they are sent as a WMI packet to WMI device... and as I've mentioned the time to process those is really slow, though it works. Seeing that as of 10.8.11 there's now a way to parse ACPI notification from EC queries how would I go about making VoodooPS2 recognize the queries coming from ACPI? (I'm quite aware of clover changing OEM to Apple, so I always patch your sources to read data from Clover instead of patching my PS2K device in ACPI).

P.S. I can see with Lenovo U410 brightness control is also handled as EC queries

            Method (_Q90, 0, NotSerialized)  // _Qxx: EC Query
            {
                Store (0x90, P80H)
                If (LGreaterEqual (OSYS, 0x07D6))
                {
                    Notify (^^^IGPU.DD02, 0x86)
                }

                Store (BRNS, ECLV)
                Notify (VPC0, 0x80)
            }

            Method (_Q91, 0, NotSerialized)  // _Qxx: EC Query
            {
                Store (0x91, P80H)
                If (LGreaterEqual (OSYS, 0x07D6))
                {
                    Notify (^^^IGPU.DD02, 0x87)
                }

                Store (BRNS, ECLV)
                Notify (VPC0, 0x80)
            }

Which I only presume is the same method for U430 that has been referred to in the last commit. So at any rate .. if display panel (IGPU.DD02) gets notified with 0x86 it means brightness up event is requested, if notify is 0x87 - brightness down. It seems common for all laptops then.. my Dell has the same kind of ACPI notifications for brightness.

I can see boolean flag to receive ACPI notifications is set:

 

[RehabMan]

New VoodooPS2Controller, Keyboard, Trackpad

Hey, @RehabMan,
Currently using IOWMIFamily (see readme on git for details) to process WMI notifications coming from two EC queries that control display brightness. These WMI codes are the same as normal PS2 scancodes would be 0xE005 and 0xE006 for Dell, but they are sent as a WMI packet to WMI device... and as I've mentioned the time to process those is really slow, though it works.

Yes, I have the same thing going on with this Lenovo U430. I looked at IOWMIFamily but found it unnecessarily complex. There is no reason to use all the WMI 'gunk' when the EC queries provide everything necessary.

Also, I wanted it to go through my mechanism for PS2 mapping so I can properly implement SysPrefs->Keyboard->"Use all F1, F2..." option. So I added some support for ACPI notifications into the PS2 driver.

Seeing that as of 10.8.11 there's now a way to parse ACPI notification from EC queries how would I go about making VoodooPS2 recognize the queries coming from ACPI? (I'm quite aware of clover changing OEM to Apple, so I always patch your sources to read data from Clover instead of patching my PS2K device in ACPI).

Note: It is easier to simply do the DSDT patch for RM,oem-id. To each his own, I guess...

P.S. I can see with Lenovo U410 brightness control is also handled as EC queries

            Method (_Q90, 0, NotSerialized)  // _Qxx: EC Query
            {
                Store (0x90, P80H)
                If (LGreaterEqual (OSYS, 0x07D6))
                {
                    Notify (^^^IGPU.DD02, 0x86)
                }

                Store (BRNS, ECLV)
                Notify (VPC0, 0x80)
            }

            Method (_Q91, 0, NotSerialized)  // _Qxx: EC Query
            {
                Store (0x91, P80H)
                If (LGreaterEqual (OSYS, 0x07D6))
                {
                    Notify (^^^IGPU.DD02, 0x87)
                }

                Store (BRNS, ECLV)
                Notify (VPC0, 0x80)
            }

Very similar (same method names, slightly different code in the methods). I used ACPIDebug to determine what query methods were called when the keys were pressed.

Then I used some DSDT patches to rewrite them such that they notify the keyboard device instead:

# Make EC-based brightness up/down work with RehabMan VoodooPS2 ACPI keyboard mechanism
into method label _Q90 parent_label EC0 replace_content
begin
    // Dell code for brightness up\n
    Notify (PS2K, 0x0206)\n
    Notify (PS2K, 0x0286)\n
end;

into method label _Q91 parent_label EC0 replace_content
begin
    // Dell code for brightness down\n
    Notify (PS2K, 0x0205)\n
    Notify (PS2K, 0x0285)\n
end;

The parameter corresponds exactly to a PS2 packet as gathered by ApplePS2Keyboard::interruptOccurred. The high-byte is either 1 or 2 (1 is normal scan code, 2 is extended 'e0' scan code). The low-bye is the scan code. You must send both down and up. These correspond to sending down & up for e006 and e005.

I was going to use the high-16 bits of the 32-bits possible for other purposes, but it turns out OS X gets it wrong and truncates the high 16-bits, so all values passed via Notify must be in the low-order 16 bits.

Which I only presume is the same method for U430 that has been referred to in the last commit. So at any rate .. if display panel (IGPU.DD02) gets notified with 0x86 it means brightness up event is requested, if notify is 0x87 - brightness down. It seems common for all laptops then.. my Dell has the same kind of ACPI notifications for brightness.

All that gunk is unnecessary, including the entire WMI device (I remove it in my u430 patches). We can just send the notification directly to PS2K and forget about the original code.

I can see boolean flag to receive ACPI notifications is set:

Yes, because Notify(PS2K, x) causes the ACPIPS2Nub::message to be called (Notify causes ::message on the object which is attached directly to the ACPI node), the nub has to send these notifications down the chain (recursively) to objects that are interested (such as ApplePS2Keyboard). This is how ApplePS2Keyboard advertises it wants these notifications.

 

[TimeWalker]

New VoodooPS2Controller, Keyboard, Trackpad

Yes, I have the same thing going on with this Lenovo U430. I looked at IOWMIFamily but found it unnecessarily complex. There is no reason to use all the WMI 'gunk' when the EC queries provide everything necessary.

Yeah, I figured WMI thing is not the most useful thing out there, but since majority of laptops from Asus have WMI as their primary notification mechanism this driver deserves a place in the universe. For my vostro only two keys used for actual controls that OSX supports (brightness up and down).. the remaining NX special keys can be parsed as default IBM ps2 scancodes.

Also, I wanted it to go through my mechanism for PS2 mapping so I can properly implement SysPrefs->Keyboard->"Use all F1, F2..." option. So I added some support for ACPI notifications into the PS2 driver.

My vostro has an option in bios (in windows mobility center too) to toggle between standard and multimedia keys layout (ie. requiring press of Fn or not). The bad thing is that I still haven't figured out what register stores this data .. its definitely not a EC register, but something from GNVS. I could keep the mode as multimedia at all times, but after booting to OSX once the mode gets stuck and nvram variables for keystore gets wiped, so F12 (boot menu) and F2 (bios setup) stop working completely and you have to reset nvram via PFlash.

So I would like to have a way to toggle the modes with your driver. With 10.8.10 experience was odd. I've created my custom maps and they worked for play/pause/prev/forward and volume control buttons.. but all the other buttons like wi-fi toggle, brightness and keyboard backligh control wouldn't invert for obvious reasons - they don't have any scancodes, they just invoke some ec query to perform certain actions... so with this latest change you are saying that it's now possible to toggle the mode for these acpi dependent buttons too ?

I used ACPIDebug to determine what query methods were called when the keys were pressed.
Then I used some DSDT patches to rewrite them such that they notify the keyboard device instead...

I was somewhat hesitant to path my dsdt since memory (operation region addresses) regions do drift for my model because of ME firmware flaws.. I have had my set of on-the-fly patches for clover this past year or so.. but since clover is able to correct regions now I guess I can use a pre-patched dsdt on this machine to alter the queries.. otherwise the patches to implement the keyboard notifications would end up huge (both _Q80 and _Q81 are way too long).

The parameter corresponds exactly to a PS2 packet as gathered by ApplePS2Keyboard::interruptOccurred. The high-byte is either 1 or 2 (1 is normal scan code, 2 is extended 'e0' scan code). The low-bye is the scan code. You must send both down and up. These correspond to sending down & up for e006 and e005.

Assuming I go down this route and alter the queries .. do I need some custom ps2 maps or breakless maps in my voodoo keyboard plist?