Contribute
Register

VoodooI2C Help and Support

Joined
Jun 2, 2019
Messages
10
Motherboard
HP EliteBook 850 G5
CPU
i7 8550U
Graphics
HD 620
Great, have you tried building latest master of all kexts with this commit reverted?
Yes, tried that. Also tried master of all kexts with VoodooGPIO submodule checked out to the last working commit. Both times no trackpad detected.

I guess one or more of the later commits in VoodooGPIO rely on 9e0b3e2e6a64c5d057cad16d94df32f962c45292.

Do you want a debug_gen from the latest master of all kexts with the commit reverted?
 
Joined
Apr 21, 2016
Messages
1,011
Motherboard
ASUS X556UA-Clover
CPU
i5-6200U
Graphics
HD 520,1366x768
Mobile Phone
  1. iOS
Yes, tried that. Also tried master of all kexts with VoodooGPIO submodule checked out to the last working commit. Both times no trackpad detected.

I guess one or more of the later commits in VoodooGPIO rely on 9e0b3e2e6a64c5d057cad16d94df32f962c45292.

Do you want a debug_gen from the latest master of all kexts with the commit reverted?
Well it should work after reverting just this one, if you were right.
How did you verify it's really the breaking commit, if you couldn't successfully test other builds you made? :p

Anyway yeah, please attach a troubleshooting archive.

You can also try the attached two builds. One named 'lag' should work for you, but be laggy on GPIO. The other one ('no-lag') should work well, if the mentioned commit is the one that broke it.
 

Attachments

  • lag.zip
    158.2 KB · Views: 53
  • no-lag.zip
    158.1 KB · Views: 64
Joined
Jun 2, 2019
Messages
10
Motherboard
HP EliteBook 850 G5
CPU
i7 8550U
Graphics
HD 620
How did you verify it's really the breaking commit, if you couldn't successfully test other builds you made? :p

I got the earlier builds working by cherry picking https://github.com/alexandred/VoodooI2C/commit/09d572f6629138a7b1d2402982df5cd6aa32e08a onto the commits.

Then confirmed that the VoodooGPIO commit was the breaking one by manually applying the submodule updates from this commit. https://github.com/alexandred/VoodooI2C/commit/62e2b0f82f4c8c77d2fd73a2a99155805b44c129 over the branch at https://github.com/alexandred/VoodooI2C/commit/bc0454ac732f35f0da4eefa9dea7144f354f8cdd.

With the VoodooI2C Satellites/VoodooI2CHID submodule update it was still working. When the Dependencies/VoodooGPIO submodule update was applied the lag started. The Dependencies/VoodooGPIO submodule update contains just the single commit.
 
Joined
Jun 2, 2019
Messages
10
Motherboard
HP EliteBook 850 G5
CPU
i7 8550U
Graphics
HD 620
Anyway yeah, please attach a troubleshooting archive.

Here's the troubleshooting archive from the latest master with VoodooGPIO#9e0b3e2e6a64c5d057cad16d94df32f962c45292 reverted.

The lag and no-lag builds behave as you predicted.
 

Attachments

  • debug_2391.zip
    3.3 MB · Views: 40
Last edited:
Joined
Apr 21, 2016
Messages
1,011
Motherboard
ASUS X556UA-Clover
CPU
i5-6200U
Graphics
HD 520,1366x768
Mobile Phone
  1. iOS
Here's the troubleshooting archive from the latest master with VoodooGPIO#9e0b3e2e6a64c5d057cad16d94df32f962c45292 reverted.

The lag and no-lag builds behave as you predicted.
Your build might be failing because of the latest VoodooI2CHID commit (57b3d2b). You can try using my fork instead, it's finalizing the override support:
Another option would be checking out 841bd6c instead, tho I'll prefer you test my fork so we can tell it's working well.

Also make sure you're actually using latest VoodooGPIO, that includes the kOSBundleRequiredRoot change.

Thanks for confirming the no-lag build actually fixes it :)
 
Joined
Jun 2, 2019
Messages
10
Motherboard
HP EliteBook 850 G5
CPU
i7 8550U
Graphics
HD 620
Your build might be failing because of the latest VoodooI2CHID commit (57b3d2b). You can try using my fork instead, it's finalizing the override support:
Another option would be checking out 841bd6c instead, tho I'll prefer you test my fork so we can tell it's working well.

Also make sure you're actually using latest VoodooGPIO, that includes the kOSBundleRequiredRoot change.

Thanks for confirming the no-lag build actually fixes it :)

That fixes it :)

Specifically, one commit back from latest on VoodooI2C (7526b0c45cf52535b0b1def2546ad9f834bb220d), then VoodooGPIO pulled to latest (ef050765e35e6903c4f237596c5ccdb599d95f46) and then the bring VoodooGPIO onto its own workloop commit in VoodooGPIO backed out.

I tried using the override-support fork, but the Build option in Xcode was greyed out.
 
Last edited:
Joined
Apr 21, 2016
Messages
1,011
Motherboard
ASUS X556UA-Clover
CPU
i5-6200U
Graphics
HD 520,1366x768
Mobile Phone
  1. iOS
That fixes it :)

Specifically, one commit back from latest on VoodooI2C (7526b0c45cf52535b0b1def2546ad9f834bb220d), then VoodooGPIO pulled to latest (ef050765e35e6903c4f237596c5ccdb599d95f46) and then the bring VoodooGPIO onto its own workloop commit in VoodooGPIO backed out.

I tried using the override-support fork, but the Build option in Xcode was greyed out.
That's odd, how did you do it?
You can try this, if you didn't:
Bash:
# cd to VoodooI2CHID directory
git remote add ben https://github.com/ben9923/VoodooI2CHID.git
git pull ben override-support
 
Joined
Jun 2, 2019
Messages
10
Motherboard
HP EliteBook 850 G5
CPU
i7 8550U
Graphics
HD 620
That's odd, how did you do it?
You can try this, if you didn't:
Bash:
# cd to VoodooI2CHID directory
git remote add ben https://github.com/ben9923/VoodooI2CHID.git
git pull ben override-support


Ok, my mistake. I checked out VoodooI2CHID over the main VoodooI2C directory.

The override-support branch of VoodooI2CHID does work with the latest VoodooI2C and the latest VoodooI2GPIO with the bring VoodooGPIO onto its own workloop commit backed out.
 
Joined
Nov 28, 2012
Messages
44
Motherboard
Dell 5570, Gigabyte B460 Aorus Pro
CPU
i5-8250U, i7-10700K
Graphics
UHD620, UHD630
Mac
  1. iMac
  2. MacBook Air
Mobile Phone
  1. iOS
I could fix the lagging/freezing happened since 2.1.4+ but you've been discussing it here. The commits causing the lagging are two, which was done on 12/23/2018.

IOWorkLoop* VoodooGPIO::getWorkLoop() { ...... }
IOWorkLoop* VoodooI2CControllerDriver::getWorkLoop() { ..... }

Simply removing these two functions solves the issue. But I think there are more.

  • Private pointer, work_loop and workLoop, are used without initialization.
  • These two pointers are also used inside the getWorkLoop(), outside, mixed in different functions.
  • getWorkLoop() is declared public in VoodooI2CDeviceNub.hpp, and the other classes includes this file with a private getWorkLoop() but still use the work_loop variable declared in VoodooI2CDeviceNub.hpp.
I don't understand the exact mechanism of the getWorkLoop() yet but the developers may do it with easy.
 
Joined
Apr 21, 2016
Messages
1,011
Motherboard
ASUS X556UA-Clover
CPU
i5-6200U
Graphics
HD 520,1366x768
Mobile Phone
  1. iOS
I could fix the lagging/freezing happened since 2.1.4+ but you've been discussing it here. The commits causing the lagging are two, which was done on 12/23/2018.

IOWorkLoop* VoodooGPIO::getWorkLoop() { ...... }
IOWorkLoop* VoodooI2CControllerDriver::getWorkLoop() { ..... }

Simply removing these two functions solves the issue. But I think there are more.

  • Private pointer, work_loop and workLoop, are used without initialization.
  • These two pointers are also used inside the getWorkLoop(), outside, mixed in different functions.
  • getWorkLoop() is declared public in VoodooI2CDeviceNub.hpp, and the other classes includes this file with a private getWorkLoop() but still use the work_loop variable declared in VoodooI2CDeviceNub.hpp.
I don't understand the exact mechanism of the getWorkLoop() yet but the developers may do it with easy.
So it's not fixed for you by removing just VoodooGPIO::getWorkLoop()?

Maybe we should mark it as a const function, like the original declaration, and mark as const override in the headers?
IOService.h suggests it should be public.
Please try implementing those changes (const override, public) instead of removing those implementations of getWorkLoop(). Let us know if it works :)
 
Top