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:

• VoodooI2C.kext with its 3 plugins + VoodooI2CELAN.kext
• 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.

[mackonsti]

Good evening @ben9923 thank you for your feedback. Apologies for taking so long to reply. I had sent my Lenovo to service and the replacement keyboard took ages to arrive from the Asian factory due to the pandemic... Unfortunately the trackpad remained the same ELAN0629 😄 A month ago I managed to get it and by the time I updated Clover, kexts etc. I wanted to leave this last.

So running Clover r5136 with the latest available today VoodooI2c v2.6.5 where I installed the two only needed kexts, in this case VoodooI2C.kext and VoodooI2CELAN.kext which I confirmed that both loaded fine.

I tried adding the boot argument -vi2c-force-polling and yes, I got back a "normal" behaviour of the trackpad movements. This is great!

Here is the boot log with grep filter to "voodoo" please have a look and confirm everything seems normal?

2021-06-22 23:12:06.73 kernel[0]: (Contents\MacOS\VoodooGPIO) VoodooGPIOCannonLakeLP::Loading GPIO Data for CannonLake-LP
2021-06-22 23:12:06.73 kernel[0]: (Contents\MacOS\VoodooGPIO) VoodooGPIOCannonLakeLP::VoodooGPIO Init!
2021-06-22 23:12:06.73 kernel[0]: (Contents\MacOS\VoodooGPIO) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 0
2021-06-22 23:12:06.73 kernel[0]: (Contents\MacOS\VoodooGPIO) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 1
2021-06-22 23:12:06.73 kernel[0]: (Contents\MacOS\VoodooGPIO) VoodooGPIOCannonLakeLP::VoodooGPIO Initializing Community 2
2021-06-22 23:12:06.73 kernel[0]: (Contents\MacOS\VoodooGPIO) VoodooGPIOCannonLakeLP::GPIO Controller is already awake! Not reinitializing.
2021-06-22 23:12:06.77 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CPCIController::pci8086,9de8 Starting I2C controller
2021-06-22 23:12:06.77 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CPCIController::pci8086,9de8 Set PCI power state D0
2021-06-22 23:12:06.77 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CPCIController::pci8086,9de8 Publishing nub
2021-06-22 23:12:06.78 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CControllerDriver::pci8086,9de8 Probing controller
2021-06-22 23:12:06.78 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CControllerDriver::pci8086,9de8 Found valid Synopsys component, continuing with initialisation
2021-06-22 23:12:06.78 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CControllerDriver::pci8086,9de8 Got bus configuration values
2021-06-22 23:12:06.78 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CControllerDriver::pci8086,9de8 Publishing device nubs
2021-06-22 23:12:06.78 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CControllerDriver::pci8086,9de8 Found I2C device: ELAN0629
2021-06-22 23:12:06.78 kernel[0]: (Contents\MacOS\VoodooI2C) VoodooI2CDeviceNub::TPD0 Forced polling mode, skipping APIC/GPIO interrupts
2021-06-22 23:12:06.79 kernel[0]: (Contents\MacOS\VoodooI2CELAN) VoodooI2CELANTouchpadDriver::elan Touchpad probe
2021-06-22 23:12:06.79 kernel[0]: (Contents\MacOS\VoodooI2CELAN) VoodooI2CELANTouchpadDriver::elan ELAN device found (ELAN0629)
2021-06-22 23:12:06.79 kernel[0]: (Contents\MacOS\VoodooI2CELAN) VoodooI2CELANTouchpadDriver::elan Could not get interrupt event source, trying to fallback on polling
2021-06-22 23:12:07.00 kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x1000002f2 start
2021-06-22 23:12:07.00 kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x1000002f4 start
2021-06-22 23:12:07.00 kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x1000002f2 creating interfaces
2021-06-22 23:12:07.00 kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x1000002f4 creating interfaces
2021-06-22 23:12:07.01 kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x1000002f2 open by AppleMultitouchTrackpadHIDEventDriver 0x1000002fa (0x0)
2021-06-22 23:12:07.01 kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x1000002f4 open by AppleActuatorHIDEventDriver 0x1000002fe (0x0)

Regarding the cleaner solution, would adding a device injection for the I2C device and force-polling with boolean value "true" work? Or something like "0x01" is better? (AQ==)

	<key>PciRoot(0x0)/Pci(0x15,0x0)</key>
	<dict>
		<key>force-polling</key>
		<data>AQ==</data>
		<key>model</key>
		<string>Intel Corporation Serial I/O I2C Controller</string>
	</dict>

My device per lspci -nn is:
00:15.0 Serial bus controller [0c80]: Intel Corporation Coffee Lake Serial I/O I2C Controller #0 [8086:9de8]

Finally, the patch to the device TPD0 that you suggest is confusing to me, so your help would be appreciated. If you see the DSL attached, under Scope (_SB.PCI0.I2C0) there is Device (TPD0) which contains Method (_INI, 0, NotSerialized) as expected (I guess).

However, inside there is a condition If ((OSYS < 0x07DC)) that sets SRXO (0x0403000E, One) so even if I bypass this condition (not sure if it's ever met or not?) I see that this variable name SRXO in my DSDT is different to the one you suggest SHPO but with the same value so I am not sure if the VoodooI2C kext expects this name or not?

A search in the DSDT code shows that there exists a Method (SRXO, 2, Serialized) and further down Method (SHPO, 2, Serialized) where SHPO is used in the _INI of the Device (TPL1) instead...

I can experiment this weekend if you have time to provide a quick tip or advice; are we supposed to declare SHPO for our kext to use GPIO on this ELAN0629 trackpad ? Also, I assume that if I achieve such DSDT hot-patch, then the device injection of force-polling must be removed, correct?

Many thanks!

DSDT-ASCN50WW.zip

[kprinssu]

@mackonsti Can you please check if the issue persists with 2.7? Otherwise, I will be closing this issue in 3 days.

[mackonsti]

Hello @kprinssu thank you for taking time to look into this matter.

In my well-tuned configuration (updated OpenCore and Big Sur since then) I rebooted and disabled this force-polling key with AQ== as data and no, latest VoodooI2C 2.7.0 including its ELAN plugin did not solve this. Removing force-polling parameter (was injected in the I2C device) made the trackpad/cursor jumpy again.

Sorry 😢 Thanks for your efforts though.

[kprinssu]

@mackonsti Can you please try getting GPIO pinning to work? Polling will inherently be in superior due to constantly checking if there is any input on the I2C bus. This is quite inefficient and slow as we are wasting CPU cycles when there is no data to process.

GPIO will use interrupts which should result in a better experience over-all. I cannot provide support on how to do this, please read our documentation on how to do so.

Additionally, please consider using Open Core over Clover, please read this as to why Open Core is better: https://dortania.github.io/OpenCore-Install-Guide/why-oc.html

[mackonsti]

Hi @kprinssu yes already using OpenCore as mentioned earlier. And I do believe you that GPIO is superior to polling.

I had tried finding the values and using GPIO with the VoodooI2C guide found here, but it produced no results, I abandoned it after spending hours and dozens of reboots trying alternative/tweaked values. I think there's either a) lack of support for my ELAN touchpad, b) no support for Whiskey Lake like my hardware c) OR there's something wrong with my DSDT -- and I despite understanding a lot, I was not in a position to "code" the new section so I can get it to work.

Also as you see, there's only 1 person that had added his/her effort in the patching repo and that was 4 years ago 😞

Moreover, with OpenCore I am not using a patched DSDT, from early tests I use different SSDTs ; do you know if such a method can get results by injecting some SSDT? Switching to custom DSDT may require a lot of effort to "stabilise" it vs. the patches of SSDTs. Are you using a custom-DSDT or a mix?

I guess I can try again, with your encouragement, hoping that you can help provide some information/guidance. Let me know if you want me to create a new Issue, to avoid spamming this one. Thanks.

[ben9923]

@mackonsti Can you attach a new troubleshooting archive made with current configuration?
Add OC folder, a copy of IOReg and kernel logs (use dmesg with boot-arg msgbuf=1048576). Don't force polling for this sake.

Make sure you're using latest BIOS for your machine, as it someimes helps fixing such issues.

It is possible to "hotpatch" (use SSDTs + patches) rather than static DSDT patching for this purpose - for any purpose really :)

[mackonsti]

Please give me some time @ben9923 as I haven't done that for > 16months and I need to read again how to do this... I will update the thread once done. Thank you for your patience.

[mackonsti]

Hi @ben9923 here is my troubleshooting archive, I had the opportunity to update to latest OpenCore in the meantime.

• What is your operating system? Big Sur 11.6.4 as MacBookPro15,2
• What version of the kext (including drivers) are you using? Latest 2.7.0 VoodooI2C kext and plugin(s)
• What is your hardware configuration? ELAN0629 touchpad
• Bootloader? Latest OpenCore 0.7.9 with typical kexts (Lilu, AppleALC, VirtualSMC, WhateverGreen) plus:
  a) VoodooI2C.kext with its 3 plugins + VoodooI2CELAN.kext loaded
  b) VoodooPS2Controller.kext with only VoodooPS2Keyboard.kext plugin loaded
  N.B. The order of kexts declared in the config.plist has been validated and working
• Latest BIOS from manufacturer? Yes

Troubleshooting archive notes:

• Created via RunMe.app v2.0 (January 2022) from www.olarila.com for ease of use
• Polling was disabled in the config.plist of OpenCore
• No custom DSDT at all, only small SSDT's added targeting specific features (see my repo for details)
• Original ZIP size was 28MB so I removed fat binaries/executables to shrink its size: AppleALC, AirportItlwm and IntelBluetoothFirmware kexts; on OC folders they exist and are properly loaded
• Rebooted with SSDT_XOSI and related patch disabled, no results (but the ZIP here contains XOSI enabled)
• Any Method (DSM) are renamed as you will see
• There is no custom SSDT that fixes or changes the Device (TPD0) to add the pin value needed in GpioInt section; any template or sample DSL file or help is appreciated.

Lenovo_S145_ELAN_VoodooIC2_2.7.0.zip

Do let me know if there is something missing or required for your research. Thank you.

[mackonsti]

Hi @ben9923 and everyone, hope you are well. After studying the GPIO pinning guide and double-checking the procedure, I'd like to report that even with pinning, ELAN0629 is jumpy 😢 Please see below steps and findings:

1. Managed to find a way to disable natively my TPD0 device inside IC20 device, via SSDT, after searching on-line. Also, loaded new SSDT-TPD1.aml in OpenCore and disabled polling. Device TPD1 is available to use as name (i.e. no conflicts).

2. Managed to inject a new TPD1 device via SSDT injection and have it appear in IORegistry and load all Voodoo driver(s). I used an exact copy of DSDT's original TPD0 device, with only needed modifications. It is obvious from IORegistryExplorer that I have a different set of keys-values under TPD1 and most likely, GPIO pinning is active:
   

3. Started the hexadecimal GPIO pin calculations; entered it in SSDT alongside other values; cursor still jumpy.

Your help is welcome...

How I calculated:

1. Determining interrupt pinning situation of \SB.PCI0.I2C0.TPD0 device.
   IOInterruptSpecifiers: exists in IORegistryExplorer
   Value originally seen in IORegistryExplorer: <6e 00 00 00 03 00 00 00>
   Thus 0x6eis the device's hexadecimal APIC pin number.
   Hexadecimal pin number is greater than 0x2F so need more work.

2. In my code (i.e. original DSDT):
   Name (SBFB) code is found but doesn't contain Interrupt (...) so we are good to continue.

3. Code in DSDT and Name (SBFG) that includes GpioInt (...) contains pin value 0x0000

4. As the Method (_CRS) code does not include the Name (SBFG) which is under the root of TPD device, it's root-pinned.

5. Method (_CRS) code changed so that the values returned are well-pinned i.e.
   Return (ConcatenateResTemplate (SBFB, SBFG)) as it was (SBFB, SBFI)

6. Hackintosh reports Canon Point-LP Serial IO I2C Controller #0 for
   IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/I2C0@15

The corresponding label on the left hand side of the form GPP_XYY_IRQ for hexadecimal APIC pin number 0x6e found:

Group D:   #define GPP_D14_IRQ      0x6e
Group G:   #define GPP_G2_IRQ       0x6e

7. Looked up the label(s) in the second list, the corresponding number on the right is the decimal GPIO pin number:

Group D:    #define GPP_D14      82 = decimal GPIO pin number
Group G:    #define GPP_G2       53 = decimal GPIO pin number (alternative?)

8. Convert the hardware pin number found to a GPIO pin, to allow the driver to use the pin. During the mapping from an APIC pin to a GPIO pin, there's a label in the form GPP_XYY_IRQ or GPP_XYY where "X" is the GPP identifier I am looking for.

X="D" or X="G"

Found the GPP of the pin in the final list for my Canon Point-LP. A GPP with the form CHIPSET_GPP(num, base, end, gpio_base), /* GPP_X */ is:

CNL_GPP(0, 68, 92, 96),            /* GPP_D */
CNL_GPP(2, 51, 58, 64),            /* GPP_G */

Convert my hardware pin to a usable GPIO pin: take the decimal GPIO pin number found, subtract the base, then add the gpio_base. The result is my GPIO pin number:

GPP_D: 82 - 68 + 96 = 110 -> 0x6E
GPP_G: 53 - 51 + 64 =  66 -> 0x42

This is my hexadecimal GPIO pin.

Note that (in very rare cases), the corresponding GPIO hexadecimal pin will NOT work. In this case, you can try some of the common values such as 0x17, 0x1B, 0x34 and 0x55
Once you have a (candidate) hexadecimal GPIO pin, you can add it into the SBFG name under the \\ Pin List comment.

I tired 0x6e (surprisingly the same number as my APIC pin, is this normal?)
Tried 0x42 as well as alterantives 0x17, 0x1B, 0x34 and 0x55. Still jumpy.

---

Questions, with my advance thanks for your reply:

a) If the wrong hexadecimal GPIO pin is used, it the trackpad supposed to respond even if jumpy or appear dead?

b) From my screenshot above of IORegistryExplorer, do you believe that the driver for GPIO pinning is properly loaded/connected, despite the bad value?

c) Could this jumpy-state be related to IRQs i.e. interrupts? How can I find the interrupt used?

d) Could it be that my actual hardware does not support pinning at all or is this not the case with ELAN trackpads?

e) Despite having found the correct GPIO pin, could some code in the SSDT/DSDT cause this jumpiness?

f) Although my hardware (Whiskey Lake) is reported as Canon Point-LP the links on the "GPIO Pinning Guide" point to URLs that mention "Canon Lake" is it safe to assume that they are actually the correct references? (just exclude a possible mistake).

g) The following kernel logs are found (with Release version of VoodooI2C, not Debug or Symols as I don't know how to implement this) avoiding those "UUID failure" lines:

% log show --style syslog -debug --info --last boot --predicate 'process == "kernel"' | grep -i voodoo | grep -v UUID   
2022-03-19 20:53:23.459325+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000388 start
2022-03-19 20:53:23.461127+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000388 creating interfaces
2022-03-19 20:53:23.461261+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000038d start
2022-03-19 20:53:23.465030+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000038d creating interfaces
2022-03-19 20:53:23.466097+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000388 open by AppleMultitouchTrackpadHIDEventDriver 0x100000396 (0x0)
2022-03-19 20:53:23.468705+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000038d open by AppleActuatorHIDEventDriver 0x100000399 (0x0)
2022-03-19 20:53:40.165876+0100  localhost kernel[0]: (VoodooI2CELAN) <private>
2022-03-19 20:53:48.561267+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000388 new user client
2022-03-19 20:53:48.614747+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000388 open by IOHIDLibUserClient 0x100000501 (0x0)
2022-03-19 20:53:48.617316+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000388 close by IOHIDLibUserClient 0x100000501 (0x0)

SSDT-TPD1.dsl.txt

cc: @zhen-zen @kprinssu your feedback is most welcome. These latter questions could also be part of the GPIO Pinning Guide that I'd be happy to improve. Thank you.

⚠️ UPDATE 1: On IORegistryExplorer I do see value gpioIRQ at 0x8 but strangely enough, despite trying different pin values in Name (SBFG) and GpioInt, on IORegistryExplorer I always get gioPin 0x6e ! Is this normal ? Could this pin value be fixed elsewhere in ACPI code (DSDT)?

UPDATE 2: I disabled ELAN and enabled VoodooI2CHID with GPIO pin injected (via SSDT). The kext has found and is attached to TPD1 just fine (per IORegistryExplorer). Mouse pointer is fluid but always continues moving to the end of screen (rather unusable) and control is difficult. Touchpad no longer reported to Big Sur (normal?) and left-click is not working.

[mackonsti]

Hi @zhen-zen @kprinssu I'd like to request your kind assistance.

Please find attached the IOReg with polling enabled.

Lenovo_ELAN0629.ioreg.zip

I have tried a lot of SSDTs but I was not able to finally create a TPDx device that works except copying the original DSDT of my Lenovo. Pinning or Polling. So I only corrected the native TPD0 device's Method (_CRS) to Return (ConcatenateResTemplate (SBFB, SBFG)) hence got pinning activated.

Could you help me identify why (and due to what hardware parameters, via debugging) the ELAN driver despite connecting, makes the movement jumpy when polling (GPIO) ? Enabling HID kext without other changes (OC, SSDT or other) produces a smooth cursor movement but always keeps moving to the right (it is unusable).

How can I further provide debug information on all VoodooI2C kexts loaded? I added the dSYM files next to the original VoodooI2C kexts in the OpenCore kexts folder, include keepsyms=1 msgbuf=1048576 in boot-args but I don't get more data whenI run the log command... I am not familiar with this kind of symbol debugging.

% log show --style syslog -debug --info --last boot --predicate 'process == "kernel"' | grep -I voodoo

2022-03-26 15:39:03.774089+0100  localhost kernel[0]: (VoodooI2CELAN) <compose failure [UUID]>
2022-03-26 15:39:04.487278+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000387 start
2022-03-26 15:39:04.489535+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000387 creating interfaces
2022-03-26 15:39:04.489847+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000038c start
2022-03-26 15:39:04.490764+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000038c creating interfaces
2022-03-26 15:39:04.503526+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputActuatorDevice:0x10000038c open by AppleActuatorHIDEventDriver 0x100000395 (0x0)
2022-03-26 15:39:04.504307+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000387 open by AppleMultitouchTrackpadHIDEventDriver 0x100000397 (0x0)
2022-03-26 15:39:15.142720+0100  localhost kernel[0]: (VoodooI2CELAN) <compose failure [UUID]>
2022-03-26 15:39:30.457884+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000387 new user client
2022-03-26 15:39:30.459606+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000387 open by IOHIDLibUserClient 0x10000050e (0x0)
2022-03-26 15:39:30.462160+0100  localhost kernel[0]: (IOHIDFamily) VoodooInputSimulatorDevice:0x100000387 close by IOHIDLibUserClient 0x10000050e (0x0)

I am sure if you analyse my IOReg you can see what may be wrong or what we could test in your ELAN kext code as tweak.

Thank you for your time.

[mackonsti]

Hi everyone, @kprinssu @ben9923 @zhen-zen I would appreciate if a kind soul would assist me in providing detailed logs on what is going on with my hardware (ELAN0629) as pinning seems to work but is jumpy...

a) what boot arguments are required?
b) where do I place the dSYM file of VoodooI2C and plugins?
c) what kind of logs would be useful?

Thanks for your time, I understand ELAN0629 may not be a priority to fix, but you could possibly discover issues in the code that would be interesting to correct, for more touchpads...