Dell Latitude 7490 - OpenCore Bootloader - Buggy Trackpad - Support Request

[Extremeagile]

I followed the OpenCore laptop guide provided by dortania.github.io which has worked splendidly well, however I am encountering some issues with the trackpad. The cursor's movement is jumpy. When moving the cursor, or when taping to click, the cursor often jumps to a different position on the screen. Has anyone encountered a similar issue before and can provide some pointers, or has some idea of what's up here?

 

SPECIFICATIONS:

DELL Latitude 7490

CPU model - Intel Core i5 Kaby Lake-U/Y

OS Version - Mojave 10.14.6

VoodooI2C - v2.4.2

VoodooI2CHID - v1.0

 

INSTALLATION DETAILS:

Using Rehabman's hotpached SSDT-XOSI and have applied the _OSI to XOSI Rename patch to my config.plist file (see https://dortania.github.io/oc-laptop-guide/prepare-install-macos/setting-up-input-devices.html for links/details).

 

Oddly enough, the trackpad works perfectly under Clover, using Hervé's bootpack. Is there someway of transplanting the relevant sections from this clover bootpack into my vanilla opencore installation?

 

TROUBLESHOOTING ARCHIVE:

https://drive.google.com/open?id=1A3n1v9XQ_yzHsY__6bo2Y4Ltr0toZ1cl

 

[Jake Lo]

Make sure to use the same version VoodooI2C* from Hervé files, newer/ different version seems to cause the jumpy movement you mentioned.

[Extremeagile]

Tried this using VoodooI2C V2.14 and VoodooI2CHID V1.0 (copied from Hervé's files) which fixes the jumpy cursor problem but comes with a different problem: laggy cursor movement - which is even more bothersome and frustrating. 

 

I've also tried various other VoodooI2C versions (between V2.14 and V2.4.2) which generally result in one problem or the other. 

[Jake Lo]

FYI, with version v2.14, you still need to disable the Intel I2C driver from loading

I'm not sure if that is required for OpenCore, you'll just have to test on your own.

 

 

[Extremeagile]

Ah yes, Intel I2C does show as being loaded in IORegExplorer. I removed AppleIntelLpssI2C.kext, AppleIntelLpssI2CController.kext and AppleHPM.kext, reloaded kext cache, and sadly the problem sticks. I also tested an alternative opencore configuration using a custom GPI0, and no SSDT-XOSI file but the results are largely the same. Might try an upgrade to Catalina tomorrow and pray that will solve it.

[fuzeless]

Hi! I have the same Latitude 7490 (i5-8350u variant) and experienced the same buggy, jumpy, delayed trackpad (I'm on 10.15.5 btw). Have you got any updates about your situation?

Btw, how did you get the trackpad working without XOSI? I've pinned and patched my GPIO following the VoodooI2C documentation but can't use my trackpad without XOSI rename.

Thanks a lot and have a great day/night!

[Extremeagile]

Hey Fuzeless,

 

Are you using OpenCore as I was, or Clover or some other bootloader? I've resorted to using clover for the timebeing as I'm exhausted with trying so many different options and getting nowhere. The trackpad works perfectly under clover using the bootpack I linked to previously. OpenCore is another story entirely.

 

I have tried so many different configurations at this point, such as different versions of I2C and I2CHID; +- XOSI +- GPIO +- XOSI + GPIO + various hotpatches of GPIO and XOSI +- Mojave OS +- Catalina OS +- transplanting the SSDT-I2C.aml file from Hervé's bootpack.

 

Since my first post I attempted GPIO pinning the trackpad. According to the guide it is already very-well-pinned but I made some edits to the DSDT file to remove extra entries in XCRS section so that "Return (ConcatenateResTemplate (SBFB, SBFG))" was the only return statement. Also tried patching the dsdt with the three recommended patches but the  laggy trackpad behaviour was still the same.

 

Weirdly, if I pull-up the trackpad in IORegExplorer, while booted with clover, it lists values under gpioIRQ and gpioPin (see screenshot). These properties are not defined under OpenCore, even with the custom DSDT for GPIO pinning + patches. This seems relevant.  

 

If you're still experiencing issues then maybe it is worthwhile testing Herve's bootpack to see if that resolves the problem?

 

[fuzeless]

Hey Extremeagile,

 

Thank you for your detailed and thorough information!

 

I forgot to tell you in my first post, that I was using OpenCore 0.5.8. Unfortunately, using Herve's bootpack or Swung0x48's (Link) would render my Trackpad to be undetectable under macOS (I hadn't examined the issue thoroughly though, as I was in a hurry then). I might try to create my own Clover Bootloader this weekend and see if it solves the problem.

 

As for the OpenCore bootloader side, I have tried everything you listed above: from trying different version (all I2C release below v2.2 would not work with the Trackpad), to only use XOSI patch/hotpatch, etc... Weirdly enough, only the XOSI patch is necessary for the Trackpad to "work". If I remove XOSI patch and only use the GPIO pinning patch, the Trackpad wouldn't be detectable (unlike yours). Moreover, in IOReg, I don't see any children under VoodooI2CControllerDriver, unlike your IOReg on Clover (This could be the issue, like you said. Maybe VoodooI2C is not well-performed under OpenCore? Specifically OC 0.5.8?).

 

Later today I'll open up an issue on the VoodooI2C Github. You might wanna check it out .

 

Thanks a lot for your reply!

(And sorry for any grammar mistakes/shortage, English is my second language.)

 

Update: I have opened an issue on VoodooI2C Github, check it out if you can!

Update 2: I am now able to boot up Herve's bootpack. The bundled VoodooI2C didn't work, so I updated to the latest release and it works, but it would occasionally cut off while dragging or using the cursor, which is more frustrating (the buggy and jumpy trackpad bug dissapeared though). Under IOReg I can't see my Trackpad and the GPIO pin listed like yours (which is weird, given that the trackpad worked, maybe under Polling mode?). I have attached my Clover EFI below.

EFI.zip

[Extremeagile]

It's totally strange that our trackpads are responding differently under virtually the same conditions. Can you confirm if VoodooI2CHID is loading properly (I don't see it in your screenshot)? Do we even have the same trackpad? The hardware ID for my trackpad is DELL081C. If we have the same trackpad then my thoughts jump to the BIOS configuration / version. I flashed mine recently so should be on the latest version. Or else, could it be that our trackpads are flashed with different firmwares? 

 

I tried the Swung boot loader which you linked - it seems to perform exactly as Hervé's does - albeit this occasionally occurs: "but it would occasionally cut off while dragging or using the cursor, which is more frustrating (the buggy and jumpy trackpad bug dissapeared though). " however it is very slight for me (once every 10 minutes, barely noticeable). 

 

As an aside, what did you do for wi-fi? Did you replace your internal card?

 

 

[fuzeless]

So I have switched to Clover (for the Trackpad sake) and created my own patches for the Trackpad and it works perfectly now! VoodooI2C is now able to detect my Trackpad, its pinning and now works under Interrupt mode, rendering a more stable experience (see screenshots below). The laggy cursor bug I mentioned above occurs very slightly to me now, although all 2-finger gestures (like zoom, rotate) are still a hit-or-miss to me: they basically work, but not smooth. Also I have the same Trackpad as yours (Dell 081C) and my BIOS version is 1.13.1 (Downgraded from v1.14 because of undervolting issue).

 

Here's my theory for the Trackpad bug under OpenCore (I'm assuming you're using SSDT patches and not directly edit and compile your DSDT): those SSDT Trackpad patches are used to patch _STA and _CRS methods found under GPI0 and TPD1 respectively. In order for those patches to work we need to rename (or to hotpatch, under ACPI -> Patches in OC config.plist) those methods so that our patched one won't be overridden by the DSDT, and there are plenty of _STAs and _CRSs in our DSDT, so we need to rename them in some specific scopes (in this case, under _SB.PCI0.GPI0 and _SB.PCI0.I2C1.TPD1 scope). In Clover this should be easy to do: just find _STA and _CRS and replace with XSTA and XCRS with their relative target bridge (GPI0 and TPD1 respectively) and we're good to go! But under OpenCore, I can still find and replace those methods, but there are no target bridges to aim for (not that I know of), so VoodooI2C won't detect our Trackpad and it has to work under Polling mode (assume that you have renamed _OSI to XOSI). However, if we edit directly to our DSDTs instead (force those methods to return specific values instead of those ifs statements that will lead to different return values), we don't have to do those SSDT patches and hotpatches anymore. I haven't tried this because my decompiled DSDT won't compile properly due to some random errors (I'll try to fix them), so if you're able to, maybe edit your DSDT instead?

 

Aside from that trackpad woes, I haven't replaced my internal wifi card (still using Intel Dual-band Wireless AC 8265, can't find replacement card for hackintosh in my area) so I use the Ethernet port for internet in macOS. Also, does the right side of your palmrest heat up while using macOS? That doesn't happen under Windows though, and I'm a bit worried because that's the left side of the battery, and battery + heat = bad :).