Contribute
Register

VoodooI2C Help and Support

Status
Not open for further replies.
you haven't installed the VoodooI2C kexts

also make sure you have working battery status
Thanks for answer. I know, no kext yet because then I can't boot at all. The guide says I need to have a connection in IOREG at GPI0 first ,but I can not make that work yet. Maybe I have made some misstake with the SSDT-GPI0-test file in the APCI folder? But as I look at my DSDT I can't see what. For now, even if the SSDT´s are not fine-tuned things seems to work with battery etc.

That means I can't boot with the kexts Voodoo2C-2.6.5. How can I continue you think?
 

Attachments

  • Battery etc..png
    Battery etc..png
    108.2 KB · Views: 49
  • IOREG-GPI0.png
    IOREG-GPI0.png
    95.9 KB · Views: 51
  • EFI.zip
    25 MB · Views: 62
  • DSDT.aml.zip
    52.5 KB · Views: 50
The GPIO controller to attach to your GPI0 is in VoodooI2C.kext. So, without it you are not going to get anything attaching. You need to solve why it is not booting with Voodoo kexts. Do a verbose boot and see where it hangs or if you get any messages. Do the same without the kexts and see where it diverges. Make sure your config.plist is getting updated correctly after adding or removing kexts.

Also try with just VoodooI2C.kext and not any of the Voodoo plugins. The trackpad won‘t work but you might get error messages from VoodooI2C. To see the messages, add debugenhancer.kext and if it boots, you can do ‘sudo dmesg | grep Voodoo’.

It is not clear from your original post if the trackpad is working without the Voodoo kexts but with no multi-touch or it is not working at all.
 
The GPIO controller to attach to your GPI0 is in VoodooI2C.kext. So, without it you are not going to get anything attaching. You need to solve why it is not booting with Voodoo kexts. Do a verbose boot and see where it hangs or if you get any messages. Do the same without the kexts and see where it diverges. Make sure your config.plist is getting updated correctly after adding or removing kexts.

Also try with just VoodooI2C.kext and not any of the Voodoo plugins. The trackpad won‘t work but you might get error messages from VoodooI2C. To see the messages, add debugenhancer.kext and if it boots, you can do ‘sudo dmesg | grep Voodoo’.

It is not clear from your original post if the trackpad is working without the Voodoo kexts but with no multi-touch or it is not working at all.
Hi thanks for reply. I use VoodooPS2Controller.kext and with that trackpad and keyboard works good. As soon as I ad VoodooI2C.kext I get kernel panic direct at boot. But thanks a lot you gave me an idé. I disabled VoodooPS2 totally and booted with VoodooI2C+I2CHID kext and guess, it booted, and I could now see that GPI0 was connected!
Then I went the other way around and found that I could enable all, but the VoodooPS2inputkext (then there is the kernel panic).
It is good I found out that, but I2C gives no gestures or zoom possibilities yet. I feel totally stupid now, what do I miss? (I update between restarts, that I don't miss :))

Edit: I start with reading the manual again
 

Attachments

  • GPI0 working!.png
    GPI0 working!.png
    108.2 KB · Views: 79
  • Voodoo boots ok.png
    Voodoo boots ok.png
    1.6 MB · Views: 72
Last edited:
Hi thanks for reply. I use VoodooPS2Controller.kext and with that trackpad and keyboard works good. As soon as I ad VoodooI2C.kext I get kernel panic direct at boot. But thanks a lot you gave me an idé. I disabled VoodooPS2 totally and booted with VoodooI2C+I2CHID kext and guess, it booted, and I could now see that GPI0 was connected!
Then I went the other way around and found that I could enable all, but the VoodooPS2inputkext (then there is the kernel panic).
It is good I found out that, but I2C gives no gestures or zoom possibilities yet. I feel totally stupid now, what do I miss? (I update between restarts, that I don't miss :))
if VoodooPS2Controller.kext works for your trackpad then you do not need VoodooI2C.kext?
 
if VoodooPS2Controller.kext works for your trackpad then you do not need VoodooI2C.kext?
No, but am just curious to see if I can get the gestures and zoom function working. For my eyes it is quite nice on a small screen like that, and it works in windows...this laptop is just on the wrong side of having windows 11 also, but still quite nice. But you are right its not 100% necessary.
 
No, but am just curious to see if I can get the gestures and zoom function working. For my eyes it is quite nice on a small screen like that, and it works in windows...this laptop is just on the wrong side of having windows 11 also, but still quite nice. But you are right its not 100% necessary.
also it is not wise to use kexts that are not needed
 
@danilovitch Have you checked if your touch screen is a I2C device? Does it show up as a I2C HID device in windows device manager?

Both VoodooPS2Controller and VoodooI2C include VoodooInput and they clash. If you use Propertree to edit your config.plist it will warn you and offer to disable in one or the other.
 
A lot of elitebooks use SMBus, not I2C, trackpads. Might be worth checking the logging output from VoodooPS2Trackpad to see if it supports SMBus/Intertouch.
 
Dear all,

I’m writing on my ASUS UX305ua Zenbook with Skylake i5-6200u processor, which is equipped with an ELAN Trackpad.

I formerly used Clover on a Catalina set-up with a fully working trackpad via GPIO Pinning to Pin 0x55 and VoodooI2C.kext and VodooI2CELAN.kext installed.

Now I’m running a fresh installation of Monterey via OpenCore and tried to apply the necessary changes.
What I did so far:

1) Checked IORegistryExplorer: No GPIO entry => added SSDT-GPIO.aml + SSDT-XOSI.aml + „Rename _OSI to XOSI (OS)“ in config.plist
=> GPIO entry shows up

2) Checked ACPI ID of my trackpad (ETPD) in Registry explorer => is listed as ETPD@1 with 1 value for IOinteruptSpecifier <6d 00 00 00 03 00 00 00>
=> 0x6d being > 0x2F I need to proceed with GPIO pinning.

My attempt now was to use the SSDT-I2C.aml to replace the _CSR method of my Device with XCSR in SSDT which both covers renaming of SBFI to SBFB and removes „Interrupt (ResourceConsumer)…“ paragraph
I also added a respective config.plist patch „_SB.PCI0.I2C1.ETPD._CRS to _SB.PCI0.I2C1.ETPD.XCRS“ assuming this will take care for the change.

As my device seems to be unpinned, I also added the „Name (SBFG…“-chapter to the SSDT-I2C.aml including setting to PIN 0x55.

No luck so far.

With clover, I patched the DSDT.aml directly via MaciASL and the suggested patches (windows patch, I2C controller patch Skylake, GPIO patch). I don't know if this has anything to do with my issues.
My knowledge is not sufficient enough though to transfer these patches manually to my configuration.

Is someone able to point me to the right direction?
Thanks a lot!

Attached my "stock" DSDT, the IOReg file after steps taken above and an extract of my EFI with (hopefully) relevant files.
 

Attachments

  • Original_DSDT.aml
    148.6 KB · Views: 39
  • UX305UA_IOReg.ioreg
    5.5 MB · Views: 56
  • OC_Monterey_Archive.zip
    280.7 KB · Views: 49
I don't see this patch in your DSDT

# GPI0 Status patch
# Ensures that OS X can enumerate the GPI0 controller
# Written and maintained by Alexandre Daoud
into method label _STA parent_label GPI0 replace_content begin
Return (0x0F)
end;
 
Status
Not open for further replies.
Back
Top