Voodooi2c: ELAN0629 broke with 2.5.2 but worked fine with 2.4.4 (latest Catalina)

[mackonsti]

Describe the bug
My ELAN0629 touchpad became jumpy, unresponsive at times and totally non-usable after updating the main kext and plugin, from v2.4.4 to v2.5.2 without changing anything else.

Did you read the common errors documentation?
Yes but this error-issue is not described in the documentation, unfortunately.

Did you read the troubleshooting documentation?
Yes, posted my RunMe zip files before/after the issue, as well as my question to Glitter but no response by someone, for some days.

Have you searched the issue on Github, Gitter, or Google?
Yes but I could not find a concrete solution, nor did anyone else report this (with solution either).

System Environment

1. What is your operating system? Catalina 10.15.7 as MacBookPro15,2
2. What version of the drivers (including drivers) are you using? 2.4.4 and 2.5.2
3. What is your hardware configuration? ELAN0629 via polling as pinning doesn't seem to work
4. Clover and Kexts used: Clover r5123 (pre-OpenCore) and loading:
5. VoodooI2C.kext with its 3 plugins + VoodooI2CELAN.kext
6. VoodooPS2Controller.kext with _only_ VoodooPS2Keyboard.kext plugin inside

Troubleshooting Archive
I am attaching 2 x ZIPs from RunMe.app compiled files, one for v2.5.2 and one with 2.4.4 driver versions. I hope these help, please let me know if there is anything more that I can provide.

Lenovo_ELAN0629_VoodooI2C_v2.4.4.zip

Lenovo_ELAN0629_VoodooI2C_v2.5.2.zip

Additional context
The same exact Clover and kexts configuration has been used, with the only difference of changing VoodooI2C kext and ELAN plugin: hence the issue detected. Something has changed in the driver in 2.5.2 that makes ELAN0629 polling not happy at all.

What is weird is that when tested VoodooI2CHID.kext instead of VoodooI2CELAN.kext, the mouse was moving smoothly and scrolling but always kept going to the top-right corner of screen as if someone was moving it. Each time I tried to grab it, them moment I release it, it kept moving back to top-right corner of screen. Despite not a usable solution, this implies to me that the code _can_ get ELAN0629 to work smoothly; just that v2.5.2 of the plugin or core kext has something that broke it.

Thank you.

[mackonsti]

To expand a little on my setup, I do not use a fully edited/patched DSDT of my Lenovo IdeaPad S145-14iWL laptop but rather an SSD patch that adds the missing Methods:

DefinitionBlock ("SSDT-I2C0.aml", "SSDT", 2, "Clover", "I2C0", 0x00000000)
{
    External (SSH0, FieldUnitObj)
    External (SSL0, FieldUnitObj)
    External (SSD0, FieldUnitObj)
    External (FMH0, FieldUnitObj)
    External (FML0, FieldUnitObj)
    External (FMD0, FieldUnitObj)

    External (_SB_.PCI0.I2C0, DeviceObj)

    Scope (\_SB.PCI0.I2C0)  // Intel Serial I/O I2C Host Controller
    {
        Method (SSCN, 0, NotSerialized)
        {
            Return (Package (0x03) {SSH0, SSL0, SSD0})
        }

        Method (FMCN, 0, NotSerialized)
        {
            Return (Package (0x03) {FMH0, FML0, FMD0})
        }
    }
}

These Methods SSCN and FMCN don't exist in Device (_SB.PCI0.I2C0) prior to (TPD0) and are added easily via Clover hot-patch. Thanks

EDIT: Mixing kexts doesn't work i.e. VoodooI2C v2.5.2 with VoodooI2CELAN v2.4.4 doesn't work, seems main kext also changed something that breaks ELAN0629 polling mode.

EDIT: @EmotionalLove you dealt with this ELAN satellite kext before, I think, any possibility to assist and check what has changed?

[kprinssu]

@ben9923 Do you believe it's an issue related to @zhen-zen's changes to VoodooGPIO?

As I don't see why updating 2.5.2 would break things especially if you were already had set up interrupts.

[zhen-zen]

It should be good if native interrupt works as expected. It's a bit aggressive to fetch alternative GPIO configuration instead of just fallback to polling mode. If then the GPIO pin could not be initialized or re-enabled after sleep, there's no mechanism to fallback to polling mode. Which is the case of this issue. (I suppose GPIO interrupt should always work if defined in DSDT, while something breaks in _INI.)
And iirc I haven't changed other parts related to GPIO. BTW does it make sense to return kIOReturnNoInterrupt when intel_gpio_irq_set_type failed in https://github.com/VoodooI2C/VoodooGPIO/blob/master/VoodooGPIO/VoodooGPIO.cpp#L958? And then fallback to polling mode in VoodooI2C if failed. For another case that interrupt cannot be used as IRQ after sleep, it's hard to notify satellite driver about this. Haven't got enough time to review that.

[mackonsti]

Hello to both @kprinssu and @zhen-zen thank you for your feedback although I may not grasp exactly what is discussed, please remember that I only got my ELAN0629 to work via polling and _not_ interrupt (unfortunately). Not sure how this impacts your reply. Thanks again (let me know if you'd like me to test some test Kext at any time).

EDIT: A quick question, please. The missing (from my DSDT) but needed methods Method SSCN and FMCN that I see people such as myself add to activate the polling method (as a last solution) are they supposed to be part of the Trackpad code (e.g. TPD0) or the GPIO device? (e.g. I2C0) because I see different implementations, despite yielding same results with v2.5.2 of the VoodooI2C kext... Thanks.

[zhen-zen]

VoodooI2C.kext.zip
Can you try this one?

[mackonsti]

Hi @zhen-zen thank you, will gladly try it. Please, what about the ELAN plugin? Should I use the same from v2.5.2 release? This is only the main kext obviously. And what logs do you want me to provide, as well? Thanks

[zhen-zen]

I only changed VoodooI2C and VoodooGPIO so interrupt on invalid GPIO pin will not be enabled. Other satellite kexts from 2.5.2 should be good. Just related boot log should be good.

[mackonsti]

Hi @zhen-zen I tried your attached Voodoo2C kext above, with the ELAN satellite plugin from the official v2.5.2 release. It is not working, now the mouse pointer doesn't even move as badly as before :( Here is the log (kernel) since boot (containing "voo" as string):

2020-11-04 19:16:48.82 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::Loading GPIO Data for CannonLake-LP
2020-11-04 19:16:48.82 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Init!
2020-11-04 19:16:48.82 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 0
2020-11-04 19:16:48.82 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 1
2020-11-04 19:16:48.82 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 2
2020-11-04 19:16:48.82 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::GPIO Controller is already awake! Not reinitializing.
2020-11-04 19:16:48.92 kernel[0]: (kernel) VoodooI2CPCIController::pci8086,9de8 Starting I2C controller
2020-11-04 19:16:48.92 kernel[0]: (kernel) VoodooI2CPCIController::pci8086,9de8 Set PCI power state D0
2020-11-04 19:16:48.92 kernel[0]: (kernel) VoodooI2CPCIController::pci8086,9de8 Publishing nub
2020-11-04 19:16:48.92 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Probing controller
2020-11-04 19:16:48.92 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Found valid Synopsys component, continuing with initialisation
2020-11-04 19:16:48.93 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Got bus configuration values
2020-11-04 19:16:48.93 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Publishing device nubs
2020-11-04 19:16:48.93 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Found I2C device: ELAN0629
2020-11-04 19:16:48.93 kernel[0]: (kernel) VoodooI2CControllerDriver::VoodooI2CDeviceNub Warning: Incompatible APIC interrupt pin (0x6e > 0x2f)
2020-11-04 19:16:48.93 kernel[0]: (kernel) VoodooI2CControllerDriver::VoodooI2CDeviceNub Found valid interrupts from _DSM or XDSM method
2020-11-04 19:16:48.93 kernel[0]: (kernel) VoodooI2CDeviceNub::Got GPIO Controller! VoodooGPIOCannonLakeLP
2020-11-04 19:16:49.70 kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000315 start
2020-11-04 19:16:49.70 kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000315 creating interfaces
2020-11-04 19:16:49.70 kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000031b start
2020-11-04 19:16:49.71 kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000031b creating interfaces
2020-11-04 19:16:49.72 kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000315 open by AppleMultitouchTrackpadHIDEventDriver 0x10000031f (0x0)
2020-11-04 19:16:49.72 kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000031b open by AppleActuatorHIDEventDriver 0x100000322 (0x0)

Despite not getting errors that might help you, I am not having the touchpad working as nicely as with v2.4.4 unfortunately... Hope you can help further. Thanks again.

[zhen-zen]

So it sounds like a terrible GPIO pin. And what do you have without SSCN and FMCN?

[mackonsti]

Without Methods SSCN and FMCN you mean @zhen-zen ? And keeping VoodooI2C and ELAN satellite kexts loaded? No usability at all. Do you want me to provide boot logs by rebooting and excluding these Methods? (they are conveniently in a SSDT). Moment please.

Rebooted with dropping my own SSDT-I2C0.aml and as expected, touchpad is just a palmrest :-/

Last login: Wed Nov  4 19:28:41 on console
2020-11-04 19:28:25.22 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::Loading GPIO Data for CannonLake-LP
2020-11-04 19:28:25.22 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Init!
2020-11-04 19:28:25.22 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 0
2020-11-04 19:28:25.22 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 1
2020-11-04 19:28:25.22 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 2
2020-11-04 19:28:25.22 kernel[0]: (kernel) VoodooGPIOCannonLakeLP::GPIO Controller is already awake! Not reinitializing.
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CPCIController::pci8086,9de8 Starting I2C controller
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CPCIController::pci8086,9de8 Set PCI power state D0
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CPCIController::pci8086,9de8 Publishing nub
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Probing controller
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Found valid Synopsys component, continuing with initialisation
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerNub::pci8086,9de8 SSCN not implemented in ACPI tables
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerNub::pci8086,9de8 FMCN not implemented in ACPI tables
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Warning: Error getting bus config, using defaults where necessary
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Publishing device nubs
2020-11-04 19:28:25.34 kernel[0]: (kernel) VoodooI2CControllerDriver::pci8086,9de8 Found I2C device: ELAN0629
2020-11-04 19:28:25.35 kernel[0]: (kernel) VoodooI2CControllerDriver::VoodooI2CDeviceNub Warning: Incompatible APIC interrupt pin (0x6e > 0x2f)
2020-11-04 19:28:25.35 kernel[0]: (kernel) VoodooI2CControllerDriver::VoodooI2CDeviceNub Found valid interrupts from _DSM or XDSM method
2020-11-04 19:28:25.35 kernel[0]: (kernel) VoodooI2CDeviceNub::Got GPIO Controller! VoodooGPIOCannonLakeLP

These twoMethods SSCNand FMCN do not exist in the original DSDT; I add them under Scope (\_SB.PCI0.I2C0) that go where Device (TPD0) is found i.e. same scope. Other people include it in the actual Device (I2C0) that I also tried, doesn't change much; hence my question where is best to have Method (SSCN) and Method (FMCN) code declared...

But even with its bad GPIO pin, version 2.4.4 worked with polling so something drastic happened in your great kext code :-(

Would a disassembled DSDT help you if I posted it here as attachment?

UPDATE: Even adding VoodooI2CHID satellite kext, without SSCN and FMCN methods injected, nothing works.

[mackonsti]

Hello @kprinssu and @ben9923 and @zhen-zen would there be any opportunity to further debug my issue, if you have time? Thank you in advance for all your help... Not sure if other people with similar (possibly crappy GPIO pin, too) may face the issue already... Staying back at v2.4.4 is a solution but with Big Sur around the corner, not sure if further development of the VoodooI2C work will solve this or not :-(

[ben9923]

@mackonsti Sorry for the late response.
SSCN & FMCN must only exist under your I2C controller device. They have no use in any other scope.

As for your kernel logs, please add DebugEnhancer.kext and attach the output of the dmesg command. Some logs aren't showing up with the log command. Make sure you're also using latest release of VoodooI2C.

Can you add the -vi2c-force-polling boot arg with latest VoodooI2C? It should use polling mode rather than GPIO.
Alternatively, you can inject force-polling with any value under the relevant I2C controller. I'd use the boot-arg first as it's the easier approach, then switch to the cleaner property approach.

The better way would be trying to make GPIO work.
Something you may be able to try is adding this line to I2C0.TPD0._INI:

SHPO (0x0403000E, One)

You can do it by renaming the method to XINI:

Find:    5F 49 4E 49 00 A0 13 95 4F 53 59 53
Replace: 58 49 4E 49 00 A0 13 95 4F 53 59 53

Then adding an SSDT with a new I2C0.TPD0._INI that calls XINI, then the SHOP line.

[mackonsti]

Hello @ben9923 and season greetings! Allow me to come back to you in a few weeks as I sent my Lenovo with this ELAN0629 touchpad to servicing... In the meantime, if anyone else encounters the same problem with latest releases that don't work (compared to functional 2.4.4) and after trying your advice above, I hope they will be able to report their findings here. Thank you again for your kind assistance.