Contribute
Register

VoodooI2C Help and Support

Status
Not open for further replies.
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
 
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.
 
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.
 
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 :)
 
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 :)

Removing two of getWorkLoop() in both VoodooGPIO.cpp and VoodooI2CControllerDriver.cpp solves the issue. It works well. But, there would be more than that to solve it completely.
 
Last edited:
Removing two of getWorkLoop() in both VoodooGPIO.cpp and VoodooI2CControllerDriver.cpp solve the issue. It works well.
@northernlights said it's enough to remove it in VoodooGPIO. Does it still lag on your machine when keeping VoodooI2CControllerDriver unmodified?

I also suggested making those methods const and mark them as override, change access to public.
Try that instead of removing it on both classes.
What I want to add is there would be more than that to solve it completely. The values are mixed.
Not sure I understood this, do you mean you cannot build when applying those changes?
 
(removed as it's outdated)
 
Last edited:

Attachments

  • fix-workloops.zip
    841.9 KB · Views: 64
I have elan1200 i2c trackpad. I patched the dsdt adding
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, HIDG))
{
Return (HIDD (Arg0, Arg1, Arg2, Arg3, HID2))
}

If (LEqual (Arg0, TP7G))
{
Return (TP7D (Arg0, Arg1, Arg2, Arg3, SBFB, SBFG))
}

Return (Buffer (One)
{
0x00
})
}
,changing
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
and changing in the return SBFI in SBFG
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If (LLess (OSYS, 0x07DC))
{
Return (SBFB)
}

If (LEqual (SDM0, Zero))
{
Return (ConcatenateResTemplate (SBFB, SBFG))
}

Return (ConcatenateResTemplate (SBFB, SBFG))
}
}

I added in EFI/CLOVER/kexts/other voodooi2c and voodooi2chid, but it doesn't work (Version 2.2 of voodoo kexts cause me kernel panic, and voodooi2c that I found for elan1200 didn't work), Could someone help me? I upload the dsdt without my patches(in TPD0) and ioreg. In ioreg my trackpad is pci8086, a160 and iointerruptspecifier is 0x10 (less than 2f)

PS: Sorry I upload a new DSDT
 
Last edited:
Status
Not open for further replies.
Back
Top