Voodooi2c: [VoodooI2C 2.5.1] MSFT0001 trackpad not responding

[dreamwhite]

Describe the bug
Trackpad isn't working beside inside IoRegistryExplorer it's detected correctly
Did you read the common errors documentation?
Yes I did. Here you are the debug log:

log.txt

Did you read the troubleshooting documentation?
Yes, below the two versions of IoRegistryExplorer with VoodooI2C v.2.4.3 and v.2.5.1:

v.2.4.3
v2.5.1

Have you searched the issue on Github, Gitter, or Google?
Yes I did but without luck

System Environment
Please answer:

1. What is your operating system? macOS Catalina 10.15.7 19H2
2. What version of the drivers (including drivers) are you using? For this test I've used VoodooI2C v.2.5.1 and VoodooI2CHID v.1.0
3. What is your hardware configuration? Dell Inspiron 5370 i5-8250U (Intel UHD Graphics 620), 16GB DDR4 2400MHz, 256 GB SSD, MSFT0001 trackpad (ACPI name: TPD0 under I2C0)

My EFI can be downloaded here and doesn't contain any patched DSDT.

Below a SysReport of my laptop:
EFI Debug Output - Dell Inspiron 5370.zip

Additional context
Same bug seems appearing with VoodooI2C 2.4.4

[kprinssu]

Please fill out the Github issue template and then re-open this issue (please avoid creating another issue).

[dreamwhite]

Please fill out the Github issue template and then re-open this issue (please avoid creating another issue).

Alright, sorry for my stupid "iT's NoT WoRkInG". I've updated the issue as requested. Hope it contains all the necessary logs for debugging purposes

[ben9923]

Thanks for the report!

Seems like you're injecting VoodooInput.kext twice. Don't inject the one in VoodooPS2Controller, just the one in VoodooI2C.

Are you sure you really need that SSDT-GPI0? I've seen it on multiple users' machines and I believe it can do more harm than good, by messing with those variables (Especially SBRG).
Doesn't VoodooGPIO load under your GPI0 device without that SSDT, or at least without messing with SBRG?
If it does, please remove/minimize that SSDT.

While I generally think it's a configuration issue, the fact it broke by a kext update makes me think otherwise.

Once fixing those, and assuming it's still not working, please attach a troubleshooting archive made with RunMe for both last-working and latest versions.

[dreamwhite]

Thank you so much for the reply.
I'll reply in order to your statements.

Seems like you're injecting VoodooInput.kext twice. Don't inject the one in VoodooPS2Controller, just the one in VoodooI2C.

Alright, I forgot that VoodooInput was already injected via VoodooI2C~VoodooPS2~. I'll remove it from ~VoodooI2C~ VoodooPS2 and use only the one bundled with ~VoodooPS2~ VoodooI2C.

~I drinked too much when I firstly wrote this comment wtf~

Are you sure you really need that SSDT-GPI0? I've seen it on multiple users' machines and I believe it can do more harm than good, by messing with those variables (Especially SBRG).

Well, without that SSDT, my trackpad isn't working at all and GPI0 device doesn't contain any attached kext, like VoodooGPIOSunrisePointLP. Theorically, standing to @dortania "Getting started with ACPI" guide, SSDT-GPI0 should be used as a replacement for SSDT-XOSI.

Once fixing those, and assuming it's still not working, please attach a troubleshooting archive made with RunMe for both last-working and latest versions.

I'll run right now the RunMe.app and edit this comment. Stay tuned

UPDATE

Please avoid using RunMe.app since it's totally closed source and has tons of bugs (just to name a few: it clearly bugs when trying to export IoRegistry dump, it doesn't strip OC serials, it doesn't strip OC serials from SystemProfiler). I'll try to release in the following months a new RunMe script totally opensource (i'm sry maldon but i don't trust closed source code).
Anyways, I extracted the ZIP archive and stripped the serials.

RunMe.app dump with VoodooI2C v.2.4.3
RunMe.app dump with VoodooI2C v.2.5.1

@ben9923 here you are the debugging archives 👍🏻

[dreamwhite]

My fault that I didn't double checked the code of runme.app. thank you so much for letting me know that but please avoid replying if you're not helpful for the issue :/

[dreamwhite]

"but i don't trust closed source code"

wtf
Jesus, man. You're crazy or newbie?
Open script file inside app with TextEdit.app or other. Kuapkuapkuapkuapkuap

Just to be sure that I'm not stupid 😂: inside RunMe.app/Contents/MacOS there's a binary file called RunMe. Opening it with a text editor (obviously) won't produce anything:

The script you're talking about is OSX-Debug from @black-dragon74 and in that case I prefer it over a closed-source RunMe.app 😄

[kprinssu]

@noobhunters753 Please only reply if it contributes to help solving @dreamwhite's issue.

Your comment was neither constructive nor helpful to the discussion at hand.

[ben9923]

@dreamwhite OSX-Debug is fine, as long as it gets the whole troubleshooting information. I thought it doesn't support OpenCore...

First - use VoodooInput bundled in VoodooI2C, not VoodooPS2. You're using I2C for trackpad input, so use the one paired with it to avoid any compatibility issues now/in the future.

So it's a new feature of VoodooI2C that's causing you some trouble.
You did not setup a _CRS method that supports GPIO interrupts - you're running in polling mode as of v2.4.3.
New v2.5 can extract a GPIO pin from _DSM on supported devices, such as yours, but VoodooGPIO fails to use the pin it found.
Your SSDT-GPI0 seems like an immediate suspect to me. It's messing with GPIO configuration variables... Not ideal.
Does VoodooGPIO load under your controller without that SSDT (Have a look in IOReg)? Maybe just _without_ SBRG in that SSDT?
If the SSDT is necessary, I'd try hot patching the GPI0._STA method altogether instead...

Another ACPI variable it does worth setting - SDM0 = Zero. It's the one that controls whether your device will use APIC or GPIO. Zero means GPIO.

[dreamwhite]

First - use VoodooInput bundled in VoodooI2C, not VoodooPS2. You're using I2C for trackpad input, so use the one paired with it to avoid any compatibility issues now/in the future.

Alright, I'll remember it. Thank you so much for the advice

Does VoodooGPIO load under your controller without that SSDT (Have a look in IOReg)? Maybe just _without_ SBRG in that SSDT?

Well, I've created SSDT-GPI0 since I initially thought it's necessary to pin the GPI0 controller without using SSDT-XOSI. In fact, @dortania 's guide says that the SSDT is needed to force enable GPI0 for VoodooI2C to connect onto. Source

I can try disabling the loading of this SSDT and let you know if the trackpad still works.

If the SSDT is necessary, I'd try hot patching the GPI0._STA method altogether instead...

What do you mean with this? You mean using a SSDT (as I did) or using the DSDT? I would prefer keeping the SSDT and not using any type of DSDT besides it's vanilla.

Another ACPI variable it does worth setting - SDM0 = Zero. It's the one that controls whether your device will use APIC or GPIO. Zero means GPIO.

Is this the same as putting my GPI0 controller in APIC mode? If yes it makes kernel panic, even if I don't inject VoodooI2C (still to double check this with latest versions of kexts).

[ben9923]

Well, I've created SSDT-GPI0 since I initially thought it's necessary to pin the GPI0 controller without using SSDT-XOSI. In fact, @dortania 's guide says that the SSDT is needed to force enable GPI0 for VoodooI2C to connect onto. Source

I can try disabling the loading of this SSDT and let you know if the trackpad still works.

Please do :)
I didn't mean to check if it works. Check if the GPIO driver has loaded under the GPIO controller - look for it in IOReg.
What do you mean with this? You mean using a SSDT (as I did) or using the DSDT? I would prefer keeping the SSDT and not using any type of DSDT besides it's vanilla.

I meant renaming GPI0._STA to XSTA, and adding a replacement _STA that returns 0xF.
It can be done with SSDTs + ACPI renames too. Make sure you're only renaming the _STA method of GPI0, rather than all of them! You can add a couple of extra bytes before/after it for the search pattern so it only matches this one.
Is this the same as putting my GPI0 controller in APIC mode? If yes it makes kernel panic, even if I don't inject VoodooI2C (still to double check this with latest versions of kexts).

Not sure what that means. What did you do in order to make it panic?
Also notice 2.5.1 was re-released. Please re-download and re-install (It might be the source of the panic).

Just a clarification - you're not using GPIO interrupts currently (with 2.4.3), you're using polling mode.

[dreamwhite]

Please do :)

Here you are the IORegistryExplorer dump with VoodooI2C 2.5.1 freshly downloaded right now with and without SSDT-GPI0.

VoodooI2C 2.5.1 with SSDT-GPI0.ioreg.zip
VoodooI2C 2.5.1 without SSDT-GPI0.ioreg.zip

In both tests, the trackpad didn't worked (neither basic pointing... frozen pointer).

Then, under your advice, I tried adding SDM0 = Zero to SSDT-GPI0 (after removing GPEN and SBRG variables) but the PC keeps kernel panicking. Here you are a dump of the panic:

kernel_panic.txt

This panic is exactly the same behaviour as I got a few months ago when I tried putting my laptop in Interrupt mode by using modGRUBShell with setup_var 0x272 0x00 which should force Interrupt mode in vain. You can read more here

It can be done with SSDTs + ACPI renames too. Make sure you're only renaming the _STA method of GPI0, rather than all of them! You can add a couple of extra bytes before/after it for the search pattern so it only matches this one.

May I ask you if you can gently provide me the ready to use ACPI patch? I'm not well-prepared on complex ACPI hot-patching, like in this case. I would really appreciate it. You can find my SysReport on my first comment of this issue:

Below a SysReport of my laptop:
EFI Debug Output - Dell Inspiron 5370.zip

Not sure what that means. What did you do in order to make it panic?

In order to panic I simply forced SDM0 variable to Zero.
As stated above, the behaviour is the same as forcing the trackpad in Interrupt mode from modGRUBShell.efi

Just a clarification - you're not using GPIO interrupts currently (with 2.4.3), you're using polling mode.

Alright, thank you so much for the clarification and for the effort you're doing for this trackpad 😂

[ben9923]

Seems like it didn't load without the SSDT. Can you try modifying the SSDT to omit SBRG but keep GPEN (No SDM0 for that test)?

Does SDM0 make it panic in v2.4.4 as well?

Please boot with keepsyms=1 boot-arg and re-generate a panic log :)

[dreamwhite]

Seems like it didn't load without the SSDT. Can you try modifying the SSDT to omit SBRG but keep GPEN (No SDM0 for that test)?
After omitting SBRG and keeping GPEN the trackpad stil works with gestures. Below the source code of SSDT-GPI0, the output and the IORegistryExplorer dump:

kextstat_working.txt
VoodooI2C 2.4.3 + SSDT-GPI0 with only GPEN.ioreg.zip

I'll update this comment with the necessary debugging files while booting with SSDT-GPI0 with SDM0 and GPEN

~I'll reboot right now with this SSDT and send you the necessary debugging files~

~With~ If SDM0 set to One or Zero the system boots and GPI0 device is correctly detected in IORegistryExplorer. Below a dump of it:

VoodooI2C 2.4.3 + SDM0 One.ioreg.zip
VoodooI2C 2.4.3 + SDM0 Zero.ioreg.zip

~I'll make the same test with VoodooI2C 2.4.4~
Here you are the IORegistryExplorer dumps with SDM0set toOneandZero`. Both makes the trackpad works :D

VoodooI2C 2.4.4 + SDM0 One.ioreg.zip
VoodooI2C 2.4.4 + SDM0 Zero.ioreg.zip

~At this point I'll try directly VoodooI2C v2.5.1 latest release and let you know if I still get any type of issue~

YES IT WORKS WITH VoodooI2C v2.5.1 + SDM0 = Zero

VoodooI2C 2.5.1 + SDM0 Zero.ioreg.zip

@ben9923 thank you so much for your effort. It works great!
You can close this issue if you think it's closed.

TL;DR: remove SBRG from SSDT-GPI0 and added SDM0

[ben9923]

@dreamwhite Neat!
I've had a feeling that SSDT-GPI0 can mess up the GPIO device... CC @dortania

Just to keep your setup clean - keepsyms=1 is only needed to preserve debug symbols in panic logs, you probably don't need it there.
SDM0 = Zero _might_ not be necessary with v2.5+, as VoodooI2C now gets the pin from _DSM as a fallback (That discovered the problematic setup), but I'd keep it anyway as it's the primary method that's supported by your machine :)

Thanks again for the detailed reports!

[1Revenger1]

Not many of us at Dortania are super familiar with I2C patching - SSDT-GPIO though is made to make it so that the _STA method for the GPIO device returns true - we don't talk about editing values which affect the flow of methods like _INI in the ACPI guide. @ben9923
Also, I don't think CCing a org works, I didn't see anything at least.

[dreamwhite]

@ben9923 I just noticed that a new version of VoodooI2C has been released. Should I upgrade to it or it's just in a test release?
Thank you so much and have a nice day

[ben9923]

@1Revenger1 Whoops, should've mentioned you instead :P

I'd probably change the given SSDT-GPIO to _not_ set SBRG.
While it is involved in the _STA return value, it's also used for GPIO device functionality. As we've seen here - giving it an arbitrary value can break it altogether.
Some devices will suffice with GPEN, and some will be fine with neither of them. I'd suggest checking if the driver is attached to the controller before patching.

With v2.5+ of VoodooI2C I'd expect more users having such issues, as SSDT-GPIO alone was not enough for enabling GPIO interrupts in most cases, but now an alternative GPIO pin retrieval method exists.
Your guides are great, just a small improvement suggestion :)

@dreamwhite That release is there to replace 2.5.1 - re-releases aren't the best idea, as some users will still have an old version without knowing it.
I'll remove 2.5.1 altogether.

[zhen-zen]

@ben9923 @1Revenger1 one approach I come up with is like creating a SSDT for temporary use, which could be helpful to diagnose those values without ACPIDebug (I used it earlier to get something like GPEN).

For example,

    External (GPEN, FieldUnitObj)
    External (SBRG, FieldUnitObj)
    External (SDM0, FieldUnitObj)
    External (SDM1, FieldUnitObj)

    Scope (\_SB)
    {
        Device (I2CD)
        {
            Name (_HID, EisaId ("PNP0C02"))  // _HID: Hardware ID
            Name (_STA, 0x0F)  // _STA: Status
            Device (GPEN)
            {
                Method (_ADR, 0, Serialized)  // _ADR: Address
                {
                    Return (\GPEN)
                }
            }

            Device (SBRG)
            {
                Method (_ADR, 0, Serialized)  // _ADR: Address
                {
                    Return (\SBRG)
                }
            }

            Device (SDM0)
            {
                Method (_ADR, 0, Serialized)  // _ADR: Address
                {
                    Return (\SDM0)
                }
            }

            Device (SDM1)
            {
                Method (_ADR, 0, Serialized)  // _ADR: Address
                {
                    Return (\SDM1)
                }
            }
        }
    }

Edit: I wonder who created the guide to set SBRG = 1 just because it couldn't be 0?

[ben9923]

@zhen-zen Seems like a great idea, I love it :)

[dreamwhite]

@ben9923 sorry for bothering you but I've noticed that putting the PC in sleep mode makes the trackpad totally unresponsive.

Below a screenshot of the loaded Voodoo kexts:

My current EFI is the same one inside my personal repository: link

Here you are also an IORegistryExplorer dump of the system while the trackpad isn't working:

VoodooI2C 2.5.2 + SDM0 Zero + Sleep.ioreg.zip

[ben9923]

@dreamwhite Please attach a full troubleshooting archive, as before :)

[dreamwhite]

@dreamwhite Please attach a full troubleshooting archive, as before :)

Alright, I'll send you the RunMe.app with stripped serials as did before. I'll update this comment with the troubleshooting archive :)

Update

Here you are the debugging files generated using OC-gen-debug as @williambj1 suggested:

Before sleep

debug_3049 BEFORE SLEEP.zip
VoodooI2C 2.5.1 + SDM0 Zero + Before Sleep.ioreg.zip

After sleep

I don't know exactly why but with the first run of gen_debug, the IORegistryExplorer wasn't dumped. Below the Zip archive of gen_debug + IORegistryExplorer dump already included.

debug_3940 AFTER SLEEP with trackpad not working.zip

[williambj1]

@dreamwhite https://github.com/hieplpvip/OC-gen-debug

Try this.

[dreamwhite]

@dreamwhite https://github.com/hieplpvip/OC-gen-debug

Perfect! It worked better than the closed-source RunMe.app 😄

@ben9923 above you'll find all the necessary files. Please let me know if I need any type of patching and how to apply them.
Have a great day

[zhen-zen]

I suppose the pin status is cleared during sleep, maybe the pin need to be initialized again?
Something like _INI or _PS0 at https://github.com/VoodooI2C/VoodooI2CHID/blob/master/VoodooI2CHID/VoodooI2CHIDDevice.cpp#L226 ?

[dreamwhite]

I suppose the pin status is cleared during sleep, maybe the pin need to be initialized again?
Something like _INI or _PS0 at https://github.com/VoodooI2C/VoodooI2CHID/blob/master/VoodooI2CHID/VoodooI2CHIDDevice.cpp#L226 ?

Thank you so much for the reply. Theorically i should wait for another release of voodooi2c right?

[zhen-zen]

I suppose the pin status is cleared during sleep, maybe the pin need to be initialized again?
Something like _INI or _PS0 at https://github.com/VoodooI2C/VoodooI2CHID/blob/master/VoodooI2CHID/VoodooI2CHIDDevice.cpp#L226 ?

Thank you so much for the reply. Theorically i should wait for another release of voodooi2c right?

I'm not sure if the controller need to call _PS0 after wake up.

By the way, can you provide a kernel log after sleep with version 2.4?

Edit: According to the ioreg above for 2.4.3, the touchpad is in polling mode?

[zhen-zen]

Also, can you try https://github.com/zhen-zen/VoodooI2C/blob/patch-2/Documentation/SSDT-I2CD.dsl and report the values under I2CD device? You need to switch to IOACPIPlane in ioregexplorer for that.

[dreamwhite]

I suppose the pin status is cleared during sleep, maybe the pin need to be initialized again?
Something like _INI or _PS0 at https://github.com/VoodooI2C/VoodooI2CHID/blob/master/VoodooI2CHID/VoodooI2CHIDDevice.cpp#L226 ?

Thank you so much for the reply. Theorically i should wait for another release of voodooi2c right?

I'm not sure if the controller need to call _PS0 after wake up.

By the way, can you provide a kernel log after sleep with version 2.4?

Sure, here you are both IOREGs + kernel logs before and after sleep:

Before sleep IOREG + Kernel log.zip
After sleep IOREG + Kernel log.zip

Edit: According to the ioreg above for 2.4.3, the touchpad is in polling mode?

Exactly, with VoodooI2C v.2.4.3 the touchpad is in polling mode

Also, can you try https://github.com/zhen-zen/VoodooI2C/blob/patch-2/Documentation/SSDT-I2CD.dsl and report the values under I2CD device? You need to switch to IOACPIPlane in ioregexplorer for that.

If I correctly understood I simply need to add this SSDT with the current configuration (VoodooI2C 2.4.4 with SDM0 set to Zero) and send you the IORegistryExplorer dump right?

If so, I'll update this comment

Here you are the IORegistryExplorer dump relative to I2CD device:

VoodooI2C 2.4.4 + SMD0 Zero + I2CD before sleep.ioreg.zip

VoodooI2C 2.4.4 + SMD0 Zero + I2CD after sleep.ioreg.zip

Again I confirm that starting from VoodooI2C 2.4.4 with the trackpad in Interrupt mode (with SDM0 set to Zero), after a sleep/wake cycle the trackpad stops working.

[dreamwhite]

@zhen-zen sorry for bothering you but do you have any advice that fixes my trackpad problem with VoodooI2C v.2.5+?
TIA

[ben9923]

@dreamwhite Just to keep this issue alive and up-to-date, can you attach another post-sleep troubleshooting archive using latest VoodooI2C? :)

[dreamwhite]

@dreamwhite Just to keep this issue alive and up-to-date, can you attach another post-sleep troubleshooting archive using latest VoodooI2C? :)

Hi Ben, first of all marry Xmas and a happy new year to you and your dears .

I'll send you the troubleshooting archive asap under this line:

UPDATE: trackpad not working after sleep

Here you are both debug before and after sleep. Please note that I had to censor the serials manually :/

VoodooI2C 2.6.1 AFTER SLEEP - debug_15947.zip
VoodooI2C 2.6.1 BEFORE SLEEP - debug_20876.zip

[ben9923]

Hi Ben, marryfirst of all marry Xmas and a happy new year to you and your dears .

I'll send you the troubleshooting archive asap under this line:

UPDATE: trackpad not working after sleep

Here you are both debug before and after sleep. Please note that I had to censor the serials manually :/

VoodooI2C 2.6.1 AFTER SLEEP - debug_15947.zip
VoodooI2C 2.6.1 BEFORE SLEEP - debug_20876.zip

Happy new year! 🎉

Please note IOReg is missing from the archives.
Kernel logs lack VoodooI2C (and probably other logs), it's a known annoying thing we experience...
Please use this method to retrieve kext logs properly, just don't grep anything.
Thanks for the quick response!

[dreamwhite]

Hi Ben, marryfirst of all marry Xmas and a happy new year to you and your dears .
I'll send you the troubleshooting archive asap under this line:

UPDATE: trackpad not working after sleep

Here you are both debug before and after sleep. Please note that I had to censor the serials manually :/
VoodooI2C 2.6.1 AFTER SLEEP - debug_15947.zip
VoodooI2C 2.6.1 BEFORE SLEEP - debug_20876.zip

Happy new year! 🎉

Please note IOReg is missing from the archives.
Kernel logs lack VoodooI2C (and probably other logs), it's a known annoying thing we experience...
Please use this method to retrieve kext logs properly, just don't grep anything.
Thanks for the quick response!

Okay so if I correctly understand, in order to give you the kernel logs, I have to type:

sudo dmesg > ~/Desktop/Log_"$(date '+%Y-%m-%d_%H-%M-%S')".log

UPDATE: added log as you requested

BEFORE SLEEP IOREG + LOG.zip
AFTER SLEEP IOREG + LOG.zip

[ben9923]

Okay so if I correctly understand, in order to give you the kernel logs, I have to type:

sudo dmesg > ~/Desktop/Log_"$(date '+%Y-%m-%d_%H-%M-%S')".log

UPDATE: added log as you requested

BEFORE SLEEP IOREG + LOG.zip
AFTER SLEEP IOREG + LOG.zip

I really don't know how it'll perform, but please try this version:
https://app.circleci.com/pipelines/github/VoodooI2C/VoodooI2C/192/workflows/b98980ee-4a64-44e0-803b-b9237f71c7f3/jobs/701/artifacts
Basically it uses intel_pinctrl_suspend/intel_pinctrl_resume that the Linux GPIO driver is using.

Can you also add SSDT-I2CD?

BTW, does it work after sleep in polling mode? New releases have the -vi2c-force-polling boot flag.

[dreamwhite]

Okay so if I correctly understand, in order to give you the kernel logs, I have to type:

sudo dmesg > ~/Desktop/Log_"$(date '+%Y-%m-%d_%H-%M-%S')".log

UPDATE: added log as you requested

BEFORE SLEEP IOREG + LOG.zip
AFTER SLEEP IOREG + LOG.zip

I really don't know how it'll perform, but please try this version:

https://app.circleci.com/pipelines/github/VoodooI2C/VoodooI2C/192/workflows/b98980ee-4a64-44e0-803b-b9237f71c7f3/jobs/701/artifacts

Basically it uses intel_pinctrl_suspend/intel_pinctrl_resume that the Linux GPIO driver is using.

I'll test in the next hours and give you the necessary debug archives ^^

Can you also add SSDT-I2CD?

Sure, I'll send you a before and after sleep ioreg dump

BTW, does it work after sleep in polling mode? New releases have the -vi2c-force-polling boot flag.

Oh nice

UPDATE: trackpad still not working

• BEFORE SLEEP.zip
• AFTER SLEEP.zip

~I'll probably try using the boot-arg as you suggested me and let you know if it works even after sleep ^^~
The trackpad works even after sleep if I force polling-mode using the boot-arg as you suggested ^^
~I've tested the CircleCI version you told me and it works. I'll probably revert to VoodooI2C v2.6.1 stable~
And it works even with VoodooI2C v2.6.1.

Honestly I don't know if it's worth it having trackpad in Interrupt Mode. I mean: it seems to be stable with the latest release.
I'll be surely free for testing out new VoodooI2C versions ^^
Again, many thanks for the effort

[ben9923]

Basically it uses intel_pinctrl_suspend/intel_pinctrl_resume that the Linux GPIO driver is using.

I'll test in the next hours and give you the necessary debug archives ^^

Can you also add SSDT-I2CD?

Sure, I'll send you a before and after sleep ioreg dump

BTW, does it work after sleep in polling mode? New releases have the -vi2c-force-polling boot flag.

Oh nice

UPDATE: trackpad still not working

• BEFORE SLEEP.zip
• AFTER SLEEP.zip

~I'll probably try using the boot-arg as you suggested me and let you know if it works even after sleep ^^~
The trackpad works even after sleep if I force polling-mode using the boot-arg as you suggested ^^
~I've tested the CircleCI version you told me and it works. I'll probably revert to VoodooI2C v2.6.1 stable~
And it works even with VoodooI2C v2.6.1.

Honestly I don't know if it's worth it having trackpad in Interrupt Mode. I mean: it seems to be stable with the latest release.
I'll be surely free for testing out new VoodooI2C versions ^^
Again, many thanks for the effort

Ugh, sorry it didn't work.
You can also inject force-polling property with any value to the relevant I2C controller PCI device, instead.

Another thing to try is adding a _PS0 method to the trackpad device (I recall macOS should call it on wake, you may verify it somehow). In this method add this line:

SHPO (GPDI, One)

It might enable the pin after sleep...
For the External statements: SHPO is under _SB, GPDI is in the root.

[dreamwhite]

Basically it uses intel_pinctrl_suspend/intel_pinctrl_resume that the Linux GPIO driver is using.

I'll test in the next hours and give you the necessary debug archives ^^

Can you also add SSDT-I2CD?

Sure, I'll send you a before and after sleep ioreg dump

BTW, does it work after sleep in polling mode? New releases have the -vi2c-force-polling boot flag.

Oh nice

UPDATE: trackpad still not working

• BEFORE SLEEP.zip
• AFTER SLEEP.zip

~I'll probably try using the boot-arg as you suggested me and let you know if it works even after sleep ^^~
The trackpad works even after sleep if I force polling-mode using the boot-arg as you suggested ^^
~I've tested the CircleCI version you told me and it works. I'll probably revert to VoodooI2C v2.6.1 stable~
And it works even with VoodooI2C v2.6.1.
Honestly I don't know if it's worth it having trackpad in Interrupt Mode. I mean: it seems to be stable with the latest release.
I'll be surely free for testing out new VoodooI2C versions ^^
Again, many thanks for the effort

Ugh, sorry it didn't work.
You can also inject force-polling property with any value to the relevant I2C controller PCI device, instead.

Another thing to try is adding a _PS0 method to the trackpad device (I recall macOS should call it on wake, you may verify it somehow). In this method add this line:

SHPO (GPDI, One)

It might enable the pin after sleep...
For the External statements: SHPO is under _SB, GPDI is in the root.

Uhm... honestly I have a strange bug in MaciASL if I try opening my vanilla DSDT.aml
May I ask you to create for me an external SSDT to add in my EFI so I can test it with Interrupt mode?

For the external references I think that I should add something like:

External (SHP0, MethodObj)
External (GPDI, UnknownObj)

Right?

Below my SysReport:

https://github.com/dreamwhite/dell-inspiron-5370-hackintosh/blob/master/SysReport/SysReport/ACPI/DSDT.aml

[ben9923]

Uhm... honestly I have a strange bug in MaciASL if I try opening my vanilla DSDT.aml
May I ask you to create for me an external SSDT to add in my EFI so I can test it with Interrupt mode?

For the external references I think that I should add something like:

External (SHP0, MethodObj)
External (GPDI, UnknownObj)

Right?

Below my SysReport:

https://github.com/dreamwhite/dell-inspiron-5370-hackintosh/blob/master/SysReport/SysReport/ACPI/DSDT.aml

Should be like that, I believe:

External (GPDI, FieldUnitObj)
External (_SB.SHP0, MethodObj)

Remove MaciASL and re-install fresh from Acidanthera, it might help :)

[dreamwhite]

Remove MaciASL and re-install fresh from Acidanthera, it might help :)

Regarding this, I've already opened a bug-report in acidanthera and it didn't fixed the issue ._."

I'll write right now the SSDT and let you know ^^

UPDATE: with the following SSDT I can't use the trackpad after sleep ._."

Maybe that I need to initialize the method _PS0 on the main controller, aka I2C0?

[ben9923]

Remove MaciASL and re-install fresh from Acidanthera, it might help :)

Regarding this, I've already opened a bug-report in acidanthera and it didn't fixed the issue ._."

I'll write right now the SSDT and let you know ^^

UPDATE: with the following SSDT I can't use the trackpad after sleep ._."

Maybe that I need to initialize the method _PS0 on the main controller, aka I2C0?

Huh. Can you attach a full archive (+IOReg, dmesg) with that SSDT? I wonder if it changed anything.

It only seems appropriate in TPD0, it's a line from its own _INI method.
Any way to verify it's actually called, though? Maybe the good old ACPIDebug.kext...

[dreamwhite]

Remove MaciASL and re-install fresh from Acidanthera, it might help :)

Regarding this, I've already opened a bug-report in acidanthera and it didn't fixed the issue ._."

I'll write right now the SSDT and let you know ^^

UPDATE: with the following SSDT I can't use the trackpad after sleep ._."

Maybe that I need to initialize the method _PS0 on the main controller, aka I2C0?

Huh. Can you attach a full archive (+IOReg, dmesg) with that SSDT? I wonder if it changed anything.

Sure, I'll update this comment with the debug files ^^

It only seems appropriate in TPD0, it's a line from its own _INI method.

Any way to verify it's actually called, though? Maybe the good old ACPIDebug.kext...

Uhm, I never used this kext before. How should I use it? Is there any resource where to start from?

UPDATE: trackpad still not working

I'm using VoodooI2C v2.6.1 stable + SSDT-I2CD. I just forgot to dmesg the "before sleep dmesg" but I don't think it'll be useful for our debugging purposes .-.

AFTER SLEEP debug_8203.zip
BEFORE SLEEP debug_27186.zip
AFTER SLEEP dmesg.zip

[ben9923]

Huh. Can you attach a full archive (+IOReg, dmesg) with that SSDT? I wonder if it changed anything.

Sure, I'll update this comment with the debug files ^^

It only seems appropriate in TPD0, it's a line from its own _INI method.

Any way to verify it's actually called, though? Maybe the good old ACPIDebug.kext...

Uhm, I never used this kext before. How should I use it? Is there any resource where to start from?

UPDATE: trackpad still not working

I'm using VoodooI2C v2.6.1 stable + SSDT-I2CD. I just forgot to dmesg the "before sleep dmesg" but I don't think it'll be useful for our debugging purposes .-.

AFTER SLEEP debug_8203.zip
BEFORE SLEEP debug_27186.zip
AFTER SLEEP dmesg.zip

Ugh, same error...

As for the SSDT debugging, you probably want to add this SSDT:
https://github.com/RehabMan/OS-X-Clover-Laptop-Config/blob/master/hotpatch/SSDT-RMDT.dsl
Then in the _PS0 method you probably want to add something like \RMDT.PUSH("Entering TPD0._PS0")
If it's called, you should be able to see it in kernel logs (dmesg)?

Note that for some reason the dmesg output you provided lacks the first ~3.3 seconds of boot. Maybe the buffer is still too small? (I actually doubt that). Anyway there's also DebugEnhancer.kext that might do better job than adding the msgbuf boot flag, if it happens again.

[dreamwhite]

Huh. Can you attach a full archive (+IOReg, dmesg) with that SSDT? I wonder if it changed anything.

Sure, I'll update this comment with the debug files ^^

It only seems appropriate in TPD0, it's a line from its own _INI method.

Any way to verify it's actually called, though? Maybe the good old ACPIDebug.kext...

Uhm, I never used this kext before. How should I use it? Is there any resource where to start from?

UPDATE: trackpad still not working

I'm using VoodooI2C v2.6.1 stable + SSDT-I2CD. I just forgot to dmesg the "before sleep dmesg" but I don't think it'll be useful for our debugging purposes .-.
AFTER SLEEP debug_8203.zip
BEFORE SLEEP debug_27186.zip
AFTER SLEEP dmesg.zip

Ugh, same error...

As for the SSDT debugging, you probably want to add this SSDT:
https://github.com/RehabMan/OS-X-Clover-Laptop-Config/blob/master/hotpatch/SSDT-RMDT.dsl
Then in the _PS0 method you probably want to add something like \RMDT.PUSH("Entering TPD0._PS0")
If it's called, you should be able to see it in kernel logs (dmesg)?

Okay so obviously I have to add an external reference for TPD0 right?
If so:

External (\RMDT.PUSH, MethodObj)

Note that for some reason the dmesg output you provided lacks the first ~3.3 seconds of boot. Maybe the buffer is still too small? (I actually doubt that). Anyway there's also DebugEnhancer.kext that might do better job than adding the msgbuf boot flag, if it happens again.

Mmmmmh I have msgbuf=1048576 so that's kinda weird. I'll try the kext you suggested ^^

[ben9923]

Okay so obviously I have to add an external reference for TPD0 right?
If so:

External (\RMDT.PUSH, MethodObj)

Looks good.

Note that for some reason the dmesg output you provided lacks the first ~3.3 seconds of boot. Maybe the buffer is still too small? (I actually doubt that). Anyway there's also DebugEnhancer.kext that might do better job than adding the msgbuf boot flag, if it happens again.

Mmmmmh I have msgbuf=1048576 so that's kinda weird. I'll try the kext you suggested ^^

Cool.

[ben9923]

@dreamwhite I believe https://github.com/VoodooI2C/VoodooGPIO/commit/86a71e241215994e10755563c49bb943b5a91eaa should solve it :)
VoodooI2C artifacts with it here.

Please let me know if it does, and we can set a new release.

*No need for that _PS0 SSDT.

[dreamwhite]

@dreamwhite I believe VoodooI2C/VoodooGPIO@86a71e2 should solve it :)
VoodooI2C artifacts with it here.

Please let me know if it does, and we can set a new release.

Hi @ben9923, sorry for the late reply. I tested the new version you sent me but the problem is still the same :'(
The dmesg log is the same as the one I attached previously...
I haven't yet tested DebugEnhancer.kext, nor SSDT-RMDT. Do I still have to use them?

*No need for that _PS0 SSDT.

How should I interpret that statement? If I don't have to use SSDT-PS0 what do I have to do?

Again, many thanks ^^

[ben9923]

Hi @ben9923, sorry for the late reply. I tested the new version you sent me but the problem is still the same :'(
The dmesg log is the same as the one I attached previously...
I haven't yet tested DebugEnhancer.kext, nor SSDT-RMDT. Do I still have to use them?

Ugh, I really though I found it. Can you attach the new logs anyway?
As long as you see all of the logs, no need for DebugEnhancer.kext.
If you still want to verify _PS0 is actually called on wake (Would be nice to tell), go ahead with SSDT-RMDT and ACPIDebug.kext. Should be quite easy to accomplish.

*No need for that _PS0 SSDT.

How should I interpret that statement? If I don't have to use SSDT-PS0 what do I have to do?

Just... use the provided kext :P
Though you can also try using the kext _with_ the SSDT. It might actually make sense...

Again, many thanks ^^

:D

[dreamwhite]

Dear @ben9923,
I did the following steps without success:

• downloaded VoodooI2C artifacts here
• added DebugEnhancer.kext
• added ACPIDebug.kext
• added SSDT-RMDT
• removed SSDT-PS0 (in my EFI I called it SSDT-GPIO2)

Sadly, there's no log left by ACPIDebug.kext. Maybe it's incompatible with Big Sur?
Here you are the logs that you asked me for:

Archive.zip

What I've noticed is that on boot the trackpad resets itself. Maybe you need to call again a reset after sleep?

[ben9923]

Dear @ben9923,
I did the following steps without success:

• downloaded VoodooI2C artifacts here
• added DebugEnhancer.kext
• added ACPIDebug.kext
• added SSDT-RMDT
• removed SSDT-PS0 (in my EFI I called it SSDT-GPIO2)

Sadly, there's no log left by ACPIDebug.kext. Maybe it's incompatible with Big Sur?
Here you are the logs that you asked me for:

Archive.zip

What I've noticed is that on boot the trackpad resets itself. Maybe you need to call again a reset after sleep?

The kext won't log anything unless you tell it to do so. It won't happen without SSDT-PS0, having a call to \RMDT.PUSH("Entering TPD0._PS0").

I looked at the SSDT in the last archive you uploaded (No call to RMDT.PUSH). There's no need to put everything in Scope (\)
It should look like this (also added RMDT call):

    Scope (_SB.PCI0.I2C0.TPD0)
    {
        If (_OSI ("Darwin"))
        {
            Method (_PS0, 0, NotSerialized)
            {
                SHPO (GPDI, One)
                \RMDT.PUSH("Entering TPD0._PS0")
            }
        }
    }

I don'e believe resetting the trackpad itself will help... It's the GPIO controller & its ACPI configuration that's causing some issues there...

Anyway we sure can add some debug logs for the can't-be-IRQ issue after you try the proper PS0 SSDT and it still doesn't work :)
I really wonder what makes it believe it's in ACPI mode...

[dreamwhite]

Thanks for the reply ^^ I'll answer to you in order:

The kext won't log anything unless you tell it to do so. It won't happen without SSDT-PS0, having a call to \RMDT.PUSH("Entering TPD0._PS0").

Alright, I've fixed the SSDT and here's the source code:

I'm rebooting right now and send you the necessary logs to check if there's any misconfiguration in ACPI .-.

UPDATE: Now I see ACPIDebug in logs

Here you are the logs you asked for. My fault that didn't wrote correctly the ssdt :P
Archive.zip

It seems that TPD0 device enters in PS0 on boot but never after sleep. I'm getting mad 😃

Maybe that intel_pinctrl_resume(); needs to be called twice? (that's a stupid hypothesis I'm thinking about)

[ben9923]

Thanks for the reply ^^ I'll answer to you in order:

The kext won't log anything unless you tell it to do so. It won't happen without SSDT-PS0, having a call to \RMDT.PUSH("Entering TPD0._PS0").

Alright, I've fixed the SSDT and here's the source code:

I'm rebooting right now and send you the necessary logs to check if there's any misconfiguration in ACPI .-.

UPDATE: Now I see ACPIDebug in logs

Here you are the logs you asked for. My fault that didn't wrote correctly the ssdt :P
Archive.zip

It seems that TPD0 device enters in PS0 on boot but never after sleep. I'm getting mad 😃

Maybe that intel_pinctrl_resume(); needs to be called twice? (that's a stupid hypothesis I'm thinking about)

Try this set of kexts. VoodooI2CHID here will call _PS0 on wake too.
https://app.circleci.com/pipelines/github/VoodooI2C/VoodooI2C/194/workflows/909523d4-c97e-49bf-af7e-69fa36ba0607/jobs/703/artifacts

I still believe it's a problem with VoodooGPIO, so even if this one does work, I don't think it's the proper solution.
Anyway if it doesn't, let me know and we'll debug VoodooGPIO further (And won't touch VoodooI2CHID...)

[dreamwhite]

Try this set of kexts. VoodooI2CHID here will call _PS0 on wake too.

OMG It's finally working O_O
~Sadly in the logs there's no trace of ACPIDebug or VoodooI2C. Is this even possible?~
Here you are the post-wake log:

Log_2021-01-01_01-19-06.log.zip

[ben9923]

Try this set of kexts. VoodooI2CHID here will call _PS0 on wake too.

OMG It's finally working O_O
~Sadly in the logs there's no trace of ACPIDebug or VoodooI2C. Is this even possible?~
Here you are the post-wake log:

Log_2021-01-01_01-19-06.log.zip

Awesome!
Does it also work with this VoodooI2CHID and latest release's VoodooI2C+VoodooGPIO?

I still believe this is a workaround and the actual problem lays in VoodooGPIO, and wish we can investigate it further if you're willing to :)
Adding a custom _PS0 is not something you'll ideally need to do...

[dreamwhite]

Good morning and happy new year ^^
I'm truly amazed that even with this VoodooI2CHID and latest releases's VoodooI2C+VoodooGPIO, the trackpad is still working after a sleep-wake cycle.

At this point, I think, in my total ignorance of the subject, that the problem must be investigated into VoodooI2CHID. Am I wrong?
Many thanks for the clarifications and have a nice day ^^

~P.S. I'll try removing the custom PS0 SSDT and see if the trackpad still works. I'll update this comment asap~

UPDATE: without SSDT-PS0 the trackpad doesn't work

I tried removing SSDT-PS0 as told above, and the trackpad stopped working after sleep :c

[ben9923]

Good morning and happy new year ^^
I'm truly amazed that even with this VoodooI2CHID and latest releases's VoodooI2C+VoodooGPIO, the trackpad is still working after a sleep-wake cycle.

At this point, I think, in my total ignorance of the subject, that the problem must be investigated into VoodooI2CHID. Am I wrong?
Many thanks for the clarifications and have a nice day ^^

~P.S. I'll try removing the custom PS0 SSDT and see if the trackpad still works. I'll update this comment asap~

UPDATE: without SSDT-PS0 the trackpad doesn't work

I tried removing SSDT-PS0 as told above, and the trackpad stopped working after sleep :c

Happy new year!

Let me explain the problem better first, I don't think I did it :)
A GPIO pin (Well, pad, but for simplicity...) can be in ACPI mode, which means it cannot be used for interrupts.
When enabling an interrupt we perform this check, and if it's in ACPI mode we see the pin XXX cannot be used as IRQ message.
Apparently calling SHPO gets it out of ACPI mode and allows us to use the pin for interrupts.

Calling SHPO is only done on boot (_INI) on all DSDTs we've ever seen. It seems like on most machines (nearly 100%) the pin will stay usable even after one/many sleep/wake cycles.
A few machines, however, reset the pin state back to ACPI mode after suspension, making it unusable as IRQ, hence the error you see.
The call to SHPO in _PS0 we've added is a workaround to put it back in usable state.

The Linux kernel implemented a mechanism in its pinctrl-intel driver that saves the host ownership (AKA being in ACPI mode) in sleep, and restores it on wake so you don't need to manually enable it.
I ported the same to VoodooGPIO, but don't know why it's not working.

Here's a build of VoodooI2C + VoodooGPIO with that change + some debug logs. Please try it.
It doesn't call _PS0 on wake (It's same as release VoodooI2CHID) - so the SSDT won't make any difference here.
Please attach dmesg logs with it :)
https://app.circleci.com/pipelines/github/VoodooI2C/VoodooI2C/195/workflows/0939fce0-1879-419a-bed6-290ab3dc9a36/jobs/704/artifacts

[dreamwhite]

Okay, I got what you're explaining to me. Many thanks

Please attach dmesg logs with it :)

Here you are the logs with SSDT-PS0 since it won't make any difference here.

Archive.zip

~I'm gonna retry logging again without that SSDT and let you know ^^~
Here you are the dmesg logs without SSDT-PS0:

dmesg without ssdt-ps0.zip
It seems that it can't quit from ACPI mode :/

[ben9923]

Okay, I got what you're explaining to me. Many thanks

Please attach dmesg logs with it :)

Here you are the logs with SSDT-PS0 since it won't make any difference here.

Archive.zip

~I'm gonna retry logging again without that SSDT and let you know ^^~
Here you are the dmesg logs without SSDT-PS0:

dmesg without ssdt-ps0.zip
It seems that it can't quit from ACPI mode :/

The problem seems to be that the pin is not registered (rather than just disabled), so its pad status is not restored after wake.
I'll look into it later today :)

[ben9923]

Hey @dreamwhite
Sorry it took a bit longer...

Anyway, seems like VoodooI2CHID removed its event source on sleep & re-added it on resume, making it unregister, then re-register from VoodooGPIO interrupts, hence it didn't persist HOSTOWN (only does so for registered pins upon resume).
Please try this build of VoodooI2C + GPIO:
https://app.circleci.com/pipelines/github/VoodooI2C/VoodooI2C/198/workflows/155544d6-6184-4581-b17f-af77ac9ac62a/jobs/708/artifacts

[dreamwhite]

Hey @dreamwhite
Sorry it took a bit longer...

Anyway, seems like VoodooI2CHID removed its event source on sleep & re-added it on resume, making it unregister, then re-register from VoodooGPIO interrupts, hence it didn't persist HOSTOWN (only does so for registered pins upon resume).
Please try this build of VoodooI2C + GPIO:
https://app.circleci.com/pipelines/github/VoodooI2C/VoodooI2C/198/workflows/155544d6-6184-4581-b17f-af77ac9ac62a/jobs/708/artifacts

OH YEAH BOI, IT WORKS!

Is this a stable version or should I wait for the release one?
Many thanks again

[ben9923]

OH YEAH BOI, IT WORKS!

Is this a stable version or should I wait for the release one?
Many thanks again

Oh yeah! Finally! 🎉

It should be stable. I'll open pull requests for the involved projects, and will make a normal release once they are merged.
CC @kprinssu

Keeping this one open until then.

[ben9923]

Merged the fix to master, going to release a new version with it :)

[dreamwhite]

Merged the fix to master, going to release a new version with it :)

Thank you so much and sorry for bothering you in those months. I couldn't resist fixing VoodooI2C ^^

[ben9923]

Merged the fix to master, going to release a new version with it :)

Thank you so much and sorry for bothering you in those months. I couldn't resist fixing VoodooI2C ^^

Sure, couldn't resist to fix it myself 😄