New VoodooPS2Controller, Keyboard, Trackpad

[RehabMan]

As you expected, system behavior is different with and without VoodooPS2Trackpad.kext. Detailed test results are below. After testing variations with VoodooPS2Controller.kext v1.8.30, I found that vps2_findmousedelay=180 works when VoodooPS2Trackpad.kext is installed (vps2_findmousedelay=430 works when VoodooPS2Trackpad.kext is NOT installed). After testing with v1.8.30, I installed v1.8.32 and confirmed that it also works with the same modified vps2_findmousedelay. My current working state is VoodooPS2Controller.kext v1.8.32 (with VoodooPS2Trackpad.kext) and vps2_findmousedelay=180. My debug files for this latest configuration are attached.

A couple of notes:

1. When I first set findmousedelay=0 at the start of testing (v1.8.30 without VoodooPS2Trackpad.kext), my system experienced a kernel panic upon reboot. The screen vanished quickly (didn't have debug=0x100). I set debug=0x100 after this and never observed the kernel panic again. I don't ever see kernel panics on this system, but can't be certain that the kernel panic was caused by VoodooPS2Controller.
2. Off-topic: TRIM does not appear to be enabled on this system (even though I have the TRIM patch selected in Clover). If you have any suggestions to enable TRIM, please let me know. Thank you.

Test results with v1.8.30 (reboot after each change):
Without VoodooPS2Trackpad.kext
vps2_findmousedelay=425: Fast (good)
vps2_findmousedelay=430: Fast (good)
vps2_findmousedelay=435: Slow (bad)

With VoodooPS2Trackpad.kext
vps2_findmousedelay=175: Fast (good)
vps2_findmousedelay=180: Fast (good)
vps2_findmousedelay=185: Slow (bad)

I will change the default to 100. We'll then see if it is long enough for the laptops it was added for...

It probably makes sense for you to disable the VoodooPS2Trackpad.kext (because you know it will never start for your PS2 mouse). You can deleting it (as you already tested), or what I would recommend is disabling with ACPI.
This small SSDT will prevent each of the trackpad drivers from probing.
Save/compile it as SSDT-DisableTrackpadProbe.aml:

// For computers that either have no trackpad (eg. desktop with PS2 mouse)
// or laptops without any support by VoodooPS2Trackpad.kext, you can disable
// each of the trackpad drivers, such that they don't probe.
//
// This can improve the reliability of VoodooPS2Mouse.kext and is more efficient as well.
DefinitionBlock("", "SSDT", 2, "hack", "ps2", 0)
{
    Name(_SB.PCI0.LPCB.PS2K.RMCF, Package()
    {
        "Synaptics TouchPad", Package()
        {
            "DisableDevice", ">y",
        },
        "ALPS GlidePoint", Package()
        {
            "DisableDevice", ">y",
        },
        "Sentelic FSP", Package()
        {
            "DisableDevice", ">y",
        },
    })
}
//EOF

 

[deeveedee]

I will change the default to 100. We'll then see if it is long enough for the laptops it was added for...

It probably makes sense for you to disable the VoodooPS2Trackpad.kext (because you know it will never start for your PS2 mouse). You can deleting it (as you already tested), or what I would recommend is disabling with ACPI.
This small SSDT will prevent each of the trackpad drivers from probing.
Save/compile it as SSDT-DisableTrackpadProbe.aml:

// For computers that either have no trackpad (eg. desktop with PS2 mouse)
// or laptops without any support by VoodooPS2Trackpad.kext, you can disable
// each of the trackpad drivers, such that they don't probe.
//
// This can improve the reliability of VoodooPS2Mouse.kext and is more efficient as well.
DefinitionBlock("", "SSDT", 2, "hack", "ps2", 0)
{
    Name(_SB.PCI0.LPCB.PS2K.RMCF, Package()
    {
        "Synaptics TouchPad", Package()
        {
            "DisableDevice", ">y",
        },
        "ALPS GlidePoint", Package()
        {
            "DisableDevice", ">y",
        },
        "Sentelic FSP", Package()
        {
            "DisableDevice", ">y",
        },
    })
}
//EOF

Thanks, @RehabMan. This SSDT did not work for me, so it could be that I did it wrong. Just to be clear, I should be able to copy the SSDT-DisableTrackpadProbe.dsl above, compile and save to CLOVER/ACPI/patched/SSDT-DisableTrackpadProbe.aml, and my system should behave as though I deleted VoodooPS2Trackpad.kext (requiring vps2_findmousedelay=430). Correct?

If so, that did NOT work for me. With SSDT-DisableTrackpadProbe.aml in CLOVER/ACPI/patched, I still needed vps2_findmousedelay=175. My system is still as shown in debug_ps2_v1.8.3.zip debug files from my previous post. This works for me, but if I can do anything to test/help, let me know.

 

[RehabMan]

Thanks, @RehabMan. This SSDT did not work for me, so it could be that I did it wrong. Just to be clear, I should be able to copy the SSDT-DisableTrackpadProbe.dsl above, compile and save to CLOVER/ACPI/patched/SSDT-DisableTrackpadProbe.aml, and my system should behave as though I deleted VoodooPS2Trackpad.kext (requiring vps2_findmousedelay=430). Correct?

If so, that did NOT work for me. With SSDT-DisableTrackpadProbe.aml in CLOVER/ACPI/patched, I still needed vps2_findmousedelay=175. My system is still as shown in debug_ps2_v1.8.3.zip debug files from my previous post. This works for me, but if I can do anything to test/help, let me know.

No "Problem Reporting" files attached (any change requires new files).
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/

 

[deeveedee]

@RehabMan - I asked a yes/no question. If the answer is yes, then I'll attach my problem reporting files.

 

[RehabMan]

@RehabMan - I asked a yes/no question. If the answer is yes, then I'll attach my problem reporting files.

It is not possible to predict what should happen regarding findmousedelay.
It is only possible to predict that with the SSDT-DisableTrackpadProbe.aml in ACPI/patched (assuming it is coded for the correct ACPI path), that all the trackpad probe methods will do an early exit.
You can read the VoodooPS2 source if you wish to understand how DisableDevice affects execution of probe.

Disabling the trackpad drivers with early probe exit has a similar effect to deleting the kext, but obviously not exactly the same.

Note that as far as kernel logs, you'll only be able to tell for sure for some of the drivers in the debug version (since some don't write any logs in probe in the release version).

 

[deeveedee]

It is not possible to predict what should happen regarding findmousedelay.
It is only possible to predict that with the SSDT-DisableTrackpadProbe.aml in ACPI/patched (assuming it is coded for the correct ACPI path), that all the trackpad probe methods will do an early exit.
You can read the VoodooPS2 source if you wish to understand how DisableDevice affects execution of probe.

Note that as far as kernel logs, you'll only be able to tell for sure for some of the drivers in the debug version (since some don't write any logs in probe in the release version).

Ok - that makes sense. I examined the DSDT and it looks to my amateur/untrained eyes like the SSDT is coded for the correct ACPI path. I expected application of the SSDT to mimic the behavior I observed when I deleted VoodooPS2Trackpad.kext (which was that I could relax the findmousedelay (from 180 to 430). Instead, I still needed the lower findmousedelay (with application of the SSDT) for responsive mouse movement. With the SSDT, I don't notice any difference in mouse/system behavior or any change in required boot args. If that is to be expected, then everything looks good. My gen_debug files with the SSDT are attached.

 

[RehabMan]

Ok - that makes sense. I examined the DSDT and it looks to my amateur/untrained eyes like the SSDT is coded for the correct ACPI path. I expected application of the SSDT to mimic the behavior I observed when I deleted VoodooPS2Trackpad.kext (which was that I could relax the findmousedelay (from 180 to 430). Instead, I still needed the lower findmousedelay (with application of the SSDT) for responsive mouse movement. With the SSDT, I don't notice any difference in mouse/system behavior or any change in required boot args. If that is to be expected, then everything looks good. My gen_debug files with the SSDT are attached.

Hmmm... no kernel log here.

 

[deeveedee]

Hmmm... no kernel log here.

If gen_debug didn't produce it, I don't know why. Is the attached what you're looking for?

 

[RehabMan]

If gen_debug didn't produce it, I don't know why.

I think 'log' is generally very broken in Sierra. Apple fixed most of the problems with it in High Sierra.

Is the attached what you're looking for?

It has this:

2018-05-06 09:35:55.060771-0400  localhost kernel[0]: (VoodooPS2Trackpad) VoodooPS2SynapticsTouchPad: Version 1.8.32 starting on OS X Darwin 16.7.
2018-05-06 09:35:55.223748-0400  localhost kernel[0]: (VoodooPS2Trackpad) VoodooPS2Trackpad: Identify TouchPad command returned incorrect byte 2 (of 3): 0x00

Which, if this time "2018-05-06 09:35:55.060771-0400" represents a boot you had SSDT-DisableTrackpadProbe.aml active, .. indicates it is not working.

 

[RehabMan]

I think 'log' is generally very broken in Sierra. Apple fixed most of the problems with it in High Sierra.



It has this:

2018-05-06 09:35:55.060771-0400  localhost kernel[0]: (VoodooPS2Trackpad) VoodooPS2SynapticsTouchPad: Version 1.8.32 starting on OS X Darwin 16.7.
2018-05-06 09:35:55.223748-0400  localhost kernel[0]: (VoodooPS2Trackpad) VoodooPS2Trackpad: Identify TouchPad command returned incorrect byte 2 (of 3): 0x00

Which, if this time "2018-05-06 09:35:55.060771-0400" represents a boot you had SSDT-DisableTrackpadProbe.aml active, .. indicates it is not working.

Found/fixed bug:
https://github.com/RehabMan/OS-X-Vo...mmit/36ae070f752a6cdd1f1aa8d2baa5d099284939b3

Try with 1.8.34 (just uploaded to bitbucket).