Trackpad randomly stops working in polling mode

[hieplpvip]

Specs

• Asus Zenbook UX410
• ELAN1200 (buggy GPIO pinning so I have to use polling)

Problem

Trackpad randomly stops working: the cursor wouldn't move. Sleeping and waking make it work again.

Log files

will upload when I have them

[ghost]

Same happening to me. ELAN1200 with buggy DSDT.

[black-dragon74]

I can confirm it happens on ASUS ROG GL-503.

ELAN 1200, polling mode. Can't use GPIO interrupts yet as it is not supported for CFL.

P.S: If you leave your trackpad for sometime it will start working automatically just it way it stopped. Putting to sleep and waking up always works though.

Regards

[williambj1]

Met once, still need to confirm on my device

[LeeBinder]

for Asus Laptops, maybe whatnameisit's polling SSDT + ACPI entry help:
tctien342/Asus-Vivobook-S510UA-Hackintosh#25
He created it for his X510UA-BQ490, also with ELAN1200.

[whatnameisit]

I created the SSDT and Clover rename based on the one provided by @tctien342 and with helps from Ben at VoodooI2C troubleshooting chatroom...credits should go where they're supposed to :)
And also @williambj1 to download the patch Ben told me to implement.

[LeeBinder]

;) allright. Do you know the differences betw. 1200 and 1300 in regards to polling and SSDT modding?

[whatnameisit]

@LeeBinder , I just began using VoodooI2C with my Asus laptop, so I don't know much. :/
Please read this guide: https://voodooi2c.github.io/#GPIO%20Pinning/GPIO%20Pinning
And I think the problem I had are somewhat different from the touchpad stopping its functionality until sleep and wake. It was that all gestures only continue to do their stuff for a few seconds, so I have to click or touch from where they stopped or redo them, i.e. I can only drag for half a second and it breaks and it leaves the file in the wrong place, and I have to start dragging from where the files are placed. Or two finger swipe scrolling stops and I have to take my fingers off and do the gesture again.

[LeeBinder]

@whatnameisit : I can somewhat relate to "I can only drag for half a second and it breaks and it leaves the file in the wrong place, and I have to start dragging from where the files are placed", even though on my ELAN1300 it was only that bad with older revisions of VoodooI2C 2.1.x - much better now but for me still not as fluent as with v.2.0.3, which is why my main macOS is still High Sierra (v.2.0.3 is legacy and does NOT work in Mojave).

Thanks for the link - with my current time provision it would be too much for me to get into right now. I'm pretty happy with your polling SSDT fix + VoodooI2C legacy 2.0.3 in High Sierra :) With v.2.1.6 regardless of in Mojave or High Sierra, I am experiencing this small delay/ "stickiness" whenever I cut/ paste/ copy: the trackpad/ "mouse" pointer stalls for half a second or so, and I can't work like that, so I stick to 10.13.6 until this maybe gets fixed some time in the future (even though Alex wrote this is inherent to the magic trackpad driver engine, but I hope someone figures it out at some point).

[williambj1]

@whatnameisit : I can somewhat relate to "I can only drag for half a second and it breaks and it leaves the file in the wrong place, and I have to start dragging from where the files are placed"

I'm facing the same issue mentioned in #190.

Video

2019-05-19 7.44.21.zip

Because of gif converting reasons, it seems to be much slower than reality, please watch the video for more accurate information.

[whatnameisit]

@williambj1 That's similar to the problem I had. First I switched from interrupts to polling and all gestures other than tapping repeated automatically so that if I click on a file/folder it automatically opens. Then I asked @ben9923 and he directed me to a hotpatch to set USTP equal to one which is kept in your repo!
As for physical buttons, I have to press harder than in Windows to perform a click or drag and keep them going. Maybe that's related to what @blankmac is saying?

[HolzMichel]

i have the same problem on Asus UX310 (Kabylake), but never noticed this issue before replacing my built in Wifi card with a DW1560. In my eyes it seems like the stops are most times then, when there are state changes in Wifi, eg. searching for Network after wake or losing connection. For me, most times when the trackpad gets stuck, the Wifi icon in the menu bar is "greyed out" or shows the "searching animation". Maybe someting strange interferences here.

[LeeBinder]

@HolzMichel : hm odd, because the WiFi is on the USB bus but the touchpad isn't.

Do you experience what you describe regardless of mode (interrupts AND polling) or only in one of the modes? I take for granted you are aware of whatnameisit's tctien342/Asus-Vivobook-S510UA-Hackintosh#25 ?

Also you should most likely better not be using USBInjectAll.kext (+ USB "UIAC" SSDT), if you do.

[HolzMichel]

I am basically using the zenbook repository of @hieplpvip, so i would have to see how to find out in which mode my trackpad is running, but as @hieplpvip mentioned in the opening post we have "(buggy GPIO pinning so I have to use polling)" with these zenbooks, so I guess we are using polling mode. I don´t use USBInjectALL.kext, i use a USBPorts.kext created in hackintool. Never had any USB issues so far. I yesterday changed from ACPIBatterymanger.kext to SMCBatterymanager.kext and since then did not notice this hangs again.

[ben9923]

@hieplpvip When it happens, can you try pressing Print Screen on your keyboard?
VoodooPS2 sends notifications for enabling/disabling the trackpad when pressing this key, I suspect a bug in VoodooPS2 might be causing that issue.

[whatnameisit]

I had the same issue with the touchpad randomly stopping. I tried to collect I2C log, but nothing showed up. Then I disabled I2C0 device (because the touchpad is at I2C1 and I2C0 isn't used) and I think it works all right, but recently I haven't used hackintosh much. So not sure if disabling I2C0 really fixed the issue. Can someone else test it?

[black-dragon74]

@whatnameisit On my machine all other I2C devices are disabled from the beginning. Doesn't seem to make a difference at all.

[whatnameisit]

@black-dragon74 :/ Then maybe the fix on my touchpad didn't work at all...

[LeeBinder]

@whatnameisit let me ask you here re. I2C0 (I'll reply to your other remarks over at tonymac's): Can you please elaborate on "turn off I2C0 device by having M(_STA) on I2C0 return Zero"? Where and how exactly do I do that - what code to alter or insert, in SSDT-ELAN-POLLING.aml/ dsl, or DSDT via hotpatch in clover.plist?

[whatnameisit]

@LeeBinder First I looked at IOReg and noticed I2C0 had VoodooI2C attached. Then I looked at my Clover-extracted DSDT and I2C0 had Method _STA inside some if condition return a nonzero value. So I decided to disable original M(_STA) by renaming it to XSTA with method header and some of its contents like in Rehabman's guide (https://www.tonymacx86.com/threads/guide-using-clover-to-hotpatch-acpi.200137/). I created a new _STA method in one of my SSDTs to return zero. After reboot, I2C0 was gone from the IOReg tree, and used the hack for about an hour and experienced no random stops. It was a pure guess and it might not really fix the issue because black-dragon74 said all I2Cx excluding the one with his touchpad are disabled from beginning. If I wait for some more time and the touchpad might stop I think. I'm on my phone so if you need the patch I can provide it when I get my hands on my machine

[LeeBinder]

Gotcha. Yes, I'd appreciate if you sent me the patch at your convenience. I'm in Europe and it's far beyond bed time, so I won't get to this again before next nite anyway, so no hurry 👍

It happens very rarely anyway, only when I'm in a hurry and "rape" my trackpad by performing too many motions in too short a time frame. I realized that in Windows 10 in the same situation, I get a lag glitch, too, but the Windows driver always manages to settle and stabilize the motion after 1 second or so.

[black-dragon74]

@LeeBinder Yes this GPIO issue can be seen in Windows too. ASUS really needs to fix this. Too many devices with the GPIO bug.

[whatnameisit]

@LeeBinder Here's the patch
config
Find: <140f5f53 544100a4 4c535441 534d4430>
Replace: <140f5853 544100a4 4c535441 534d4430>
If I remember correctly, the config patch changes the whole method

Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    Return (LSTA (SMD0))
                }

to

Method (XSTA, 0, NotSerialized)  // _STA: Status
                {
                    Return (LSTA (SMD0))
                }

so the original _STA isn't used anywhere. Please look at your own DSDT and see if you get the same Hex code as mine (please refer to https://www.tonymacx86.com/threads/guide-using-clover-to-hotpatch-acpi.200137/ if you need anything)
Then below SSDT has new _STA method to return zero and disable I2C0.
SSDT-disable-I2C0.aml.zip

[LeeBinder]

superb, will do. SSDT-disable-I2C0.aml needs to be placed into Clover/ACPI/patched IN ADDITION to SSDT-ELAN-POLLING.aml, NOT replacing it, right?

[whatnameisit]

That's right. SSDT-ELAN-POLLING.aml enables the touchpad at I2C1.ETPD in polling mode when used with VoodooI2C and the HID satellite. SSDT-disable-I2C0.aml disables the unused I2C0.

[LeeBinder]

me being silent/ not hearing from me = not experiencing any hangs whatsoever (so far and hopefully for good) 🥇

[EDIT] less but sure not solved ... :(

[LeeBinder]

@LeeBinder Here's the patch
[snip]
SSDT-disable-I2C0.aml.zip

@whatnameisit , this proves not to be a good idea anymore: with the latest VoodooI2C v.2.3 this causes kernel panic on wake from sleep for me (regardless of in GPIO or polling mode). I've been testing back and forth for a while last hour: this really seems to be the culprit, because as soon as I deactivate the hotpatch, remove the SSDT and reboot, WUpFS works fine again (for good in Mojave, not tested Catalina yet).

Maybe because of this fix:

Fix issue with some devices failing to meet the deadline in commandSleep:
• Correct IOCommandGate::commandSleep call

Thought you might want to know about this, too.

Will be observing now with v.2.3 if pointer hangs are gone for good now, hopefully..

[whatnameisit]

@LeeBinder
Thank you for reporting. I tested sleep and wake with the v2.3 kexts and I also have kp on wake.
Removing the patch to disable I2C0 fixed kp issues. I too hope the random stops would disappear with v2.3.

[LeeBinder]

@whatnameisit
glad I could save you debugging time :)

Now I hope that the really annoying regression from VoodooI2C "legacy" 2.0.3 to 2.1+ of highlighting/ dragging getting lost half way in the air constantly as perfectly described here by @williambj1 can get solved next. I am requesting that anybody affected adds their "me, too" over there so the issue gets some reinforcement. Right now there is too little subscribers over there which needs improvement, for starters.

[ben9923]

@LeeBinder @whatnameisit Could either of you reproduce this kernel panic while booting with keepsyms=1 and attach the panic log?
While you solved the panic by eliminating the patch, I'm still interested to know if we can avoid the KP altogether. Usually the expected result would be non-functional trackpad rather than a panic.

So from testing so far, no sudden stops that require a reboot?

[brunogermain]

Hello everyone. I'm reopening this because I'm actually still experiencing random trackpad stops with VoodooI2C v2.3 and Mojave.
I read this thread over and over, but I couldn't understand whether or not I should patch VoodooI2C by removing pci8086,9d60 match from VoodooI2C.kext, hotpatch my DSDT or any of those.
debug_UX310UA_Mojave.zip

[LeeBinder]

@brunogermain try https://github.com/dhinakg/VoodooI2C/releases

[brunogermain]

@brunogermain try https://github.com/dhinakg/VoodooI2C/releases

@LeeBinder just replace my kext with this?

It works, but I lost click and drag

[LeeBinder]

maybe you need to enable something in trackpad sys prefs

[brunogermain]

VoodooI2C and VoodooI2CHID. That's what I did

[LeeBinder]

Correct. I edited my previous comment

[brunogermain]

if I try to click and drag, it just opens the document or folder i click. no dragging
v2.3 from alexandred didn't have this issue

[Mateo1234454545]

@brunogermain , same problem see here : #269
Can you try this :https://github.com/daliansky/XiaoMi-Pro-Hackintosh/files/4394815/VoodooI2C.Mar.27.zip

[brunogermain]

@Mateo1234454545 , same behaviour

[Mateo1234454545]

@Mateo1234454545 , same behaviour

Can you check if you have voodooinput.kext loaded? e.g with hackintool.
If you do , disable it and reboot.

[brunogermain]

No Voodooinput.kext loaded. Actually never heard of it

[brunogermain]

I've been experimenting with different kexts and it appears that the only one working properly, but still freezing every now and then is v2.3 only until the commit of February 18.
The one I downloaded today from github (https://github.com/alexandred/VoodooI2C/releases/tag/2.3) broke dragging. Reverting to the one I downloaded one month ago (already version 2.3) brought everything back to normal

[brunogermain]

@Mateo1234454545 , Voodooinput gets loaded with last v2.3, but not with the February 2020 version. How do I disable it?

[Mateo1234454545]

You can just delete it from kexts/other , but if you do your trackpad will stop working. At least that happens for mine.

[brunogermain]

You can just delete it from kexts/other , but if you do your trackpad will stop working. At least that happens for mine.

Correct... I guess I'll stick with v2.3 before Voodooinput was added to the plugins. That one one works good, it just rarely freeze when you stress it with too many gestures. At least that's my guess

[brunogermain]

The question is: does disabling I2C0 via SSDT and removing pci8086,9d60 (to prevent KP) solve the trackpad freeze issue?

[LeeBinder]

Just FYI: dhinakg's VoodooI2C.kext 2.3.2 from https://github.com/dhinakg/VoodooI2C/releases contains VoodooInput inside VoodooI2C.kext/Contents/PlugIns!!
Also FYI, dhinakg wrote in a note that he's aware that that's not how it's desired by the other devs who request VoodooInput to please be supplied separately as an additional kext...

Can you try this :https://github.com/daliansky/XiaoMi-Pro-Hackintosh/files/4394815/VoodooI2C.Mar.27.zip

@Mateo1234454545 : I see this version does not contain VoodooInput inside VoodooI2C.kext/Contents/PlugIns. There is not ReadMe inside, so my questions are:

1. who compiled these kexts?
2. does this version require VoodooInput to be installed additionally?

[LeeBinder]

The question is: does disabling I2C0 via SSDT and removing pci8086,9d60 (to prevent KP) solve the trackpad freeze issue?

@brunogermain : try, test and report back?

[Mateo1234454545]

@LeeBinder , daliansky compiled it and no , there is no requirement for voodooinput. That's the reason , I believe, it is working well on machine.

[williambj1]

@Mateo1234454545

Understand what is VoodooInput before you speak, you are misleading others.

[brunogermain]

@LeeBinder I'm currently testing, but I don't know how to reproduce the trackpad freeze, it just happens randomly.

One more question, is there a way remove pci8086,9d60 via Clover KextsToPatch?

I wrote this to add to my config.plist:

		<dict>
			<key>Comment</key>
			<string>Remove pci8086,9d60 device from VoodooI2C</string>
			<key>Disabled</key>
			<true/>
			<key>Find</key>
			<data>
			OWQ2MA==
			</data>
			<key>InfoPlistPatch</key>
			<true/>
			<key>Name</key>
			<string>VoodooI2C</string>
			<key>Replace</key>
			<data>
			OWQ2OQ==
			</data>
		</dict>

It's disabled now, since it wasn't working.
I just deleted the line from VoodooI2C's Info.plist to prevent KP on wake from sleep

Thanks for the support!

[brunogermain]

The question is: does disabling I2C0 via SSDT and removing pci8086,9d60 (to prevent KP) solve the trackpad freeze issue?

@brunogermain : try, test and report back?

It keeps freezing. Debug attached

debug_11465.zip

[brunogermain]

@hieplpvip Since the issue is still not resolved, shouldn't this be re-opened?

[mishurov]

I agree with @brunogermain . I've got the same issue: Asus UX310, ELAN1200. I tried GPIO pinning, the touchpad works but it's unusable due to slow responses etc. thus I turned to the polling mode. In polling mode it randomly stops working for some time then randomly resumes working. So I have to plug and use a mouse while the touchpad is taking a break.

[kurtmorris]

I actually experienced this issue on my Asus UX533F using GPIO Interrupts (pin 0x55) and polling, I previously had patched my DSDT and had loaded that. I found that my ACPI tables were changing without any obvious reason usually once a month. I got fed up with re-extracting my DSDT and manually patching and I figured I would hot patch it.

I ended up hot patching the ETPD device and had to move FFCN and SSCN outside an "if" statement to get VoodooI2C to recognize the trackpad (Using renames and a I2C1 SSDT). At this point the trackpad would still freeze momentarily.

It seems it wasn't until I patched the _STA method in _SB.PCI0.GPI0 to always return 0x0F that it would stop freezing.

I renamed the method from _STA to XSTA, and modified my SSDT to reflect this.

DefinitionBlock ("", "SSDT", 2, "HIEP", "ELAN", 0)
{
    // replace Method(_STA,0,NS) in Device(GPI0)
    External(_SB.PCI0.GPI0, DeviceObj)
    Method (_SB.PCI0.GPI0._STA, 0, NotSerialized)
    {
        Return (0x0F)
    }
  
    // GPIO Pin for ETPD
    External(_SB.PCI0.I2C1.ETPD, DeviceObj)
    Scope (_SB.PCI0.I2C1.ETPD)
    {
        Name (SBFG, ResourceTemplate ()
        {
            GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,
                "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                )
                {
                    0x55 // Custom pin here
                }
        })
        Method (_CRS, 0, Serialized)
        {
            Name (SBFB, ResourceTemplate ()
            {
                I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                    0x00, ResourceConsumer, , Exclusive,
                    )
            })
            Return (ConcatenateResTemplate (SBFB, SBFG))
        }
    }
}

And my I2C1 SSDT for anyone this may help.

// Laptop: Asus UX533F. SSCN and FMCN are found inside an "if" statement in
// ACPI Tables, VoodooI2C can't work with them in this form.
// We hotpatch rename them and provide our own outside of the "if".
DefinitionBlock ("SSDT-I2C1.aml", "SSDT", 2, "OC", "I2C1", 0x00000000)
{
    // Rename Method(SSCN,0,NS) in Device(I2C1)
    // Rename Method(FMCN,0,NS) in Device(I2C1)
    External (_SB.SSH1, FieldUnitObj)
    External (_SB.SSL1, FieldUnitObj)
    External (_SB.SSD1, FieldUnitObj)
    External (_SB.FMH1, FieldUnitObj)
    External (_SB.FML1, FieldUnitObj)
    External (_SB.FMD1, FieldUnitObj)
    External(_SB.PCI0.I2C1, DeviceObj)

    Scope (\_SB.PCI0.I2C1)  // Intel Serial I/O I2C Host Controller
    {
        Method (SSCN, 0, NotSerialized)
        {
             Return (Package (0x03) {SSH1, SSL1, SSD1})
        }

        Method (FMCN, 0, NotSerialized)
        {
             Return (Package (0x03) {FMH1, FML1, FMD1})
        }
    }
}

[LeeBinder]

Thank you @kurtmorris for sharing! Which trackpad does your VivoBook have - ELAN1200, ELAN1300 or even a different one?

[kurtmorris]

@LeeBinder Sorry I should have mentioned it earlier, it's actually a ZenBook with an ELAN1200.