Contribute
Register

VoodooI2C Help and Support

Feartech

Moderator
Joined
Aug 3, 2013
Messages
27,627
Motherboard
Asus N752VX-OpenCore
CPU
i7-6700HQ / HM170
Graphics
HD 530 1920 x 1080
Mac
  1. iMac
Mobile Phone
  1. iOS
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
 
Joined
Mar 8, 2015
Messages
70
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
@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.
 
Joined
Feb 22, 2020
Messages
166
Motherboard
Dell Precision M4700
CPU
i7-3740QM
Graphics
M4000
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.
 
Joined
Aug 28, 2015
Messages
7
Motherboard
ASUS UX305UA (Clover)
CPU
i5-6200u
Graphics
HD 520; 1920x1080
Mobile Phone
  1. Android
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: 26
  • UX305UA_IOReg.ioreg
    5.5 MB · Views: 25
  • OC_Monterey_Archive.zip
    280.7 KB · Views: 29
Joined
Feb 19, 2016
Messages
200
Motherboard
ASUS ZenBook UX430UA-DH74
CPU
i7-8550U
Graphics
Intel 620 1920x1080
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;
 
Joined
Aug 28, 2015
Messages
7
Motherboard
ASUS UX305UA (Clover)
CPU
i5-6200u
Graphics
HD 520; 1920x1080
Mobile Phone
  1. Android
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;
Thanks for your reply.
The Original_DSDT.aml is my dumped DSDT without any patches.

The .zip archive contains parts of my OC Monterey EFI older including SSDTs.
The GPI0 patch should be contained in my SSDT-GPIO.aml. Don't know if this is correct though.

Code:
DefinitionBlock ("", "SSDT", 2, "hack", "ETPD", 0x00000000)
{
    External (_SB_.PCI0.GPI0, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.I2C1.ETPD, DeviceObj)    // (from opcode)

    Scope (_SB.PCI0.GPI0)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (0x0F)
        }
    }

    Scope (_SB.PCI0.I2C1.ETPD)
    {
        Name (SBFG, ResourceTemplate ()
        {
            GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,
                "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                )
                {   // Pin list
                    0x0055
                }
        })
        Method (XCRS, 0, Serialized)
        {
            Name (SBFB, ResourceTemplate ()
            {
                I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                    0x00, ResourceConsumer, , Exclusive,
                    )
            })
            Return (ConcatenateResTemplate (SBFB, SBFG))
        }
    }
}
 
Joined
Aug 28, 2015
Messages
7
Motherboard
ASUS UX305UA (Clover)
CPU
i5-6200u
Graphics
HD 520; 1920x1080
Mobile Phone
  1. Android
One step ahead...

based on your hint @starcentral I realized that I both didn't rename the GPI0 _STA method to XSTA in my SSDT and had the renaming in my config.plist inactive as well.

I changed that now. Still no working trackpad though.
New file archive attached - IOReg, DSDTs inside.
 

Attachments

  • OC_EFI_extract_UX305UA.zip
    295.6 KB · Views: 30
Last edited:
Joined
Feb 19, 2016
Messages
200
Motherboard
ASUS ZenBook UX430UA-DH74
CPU
i7-8550U
Graphics
Intel 620 1920x1080
Your GPIO patch doesn't have the patch in it, I found it in your I2C patch.

Remove your XCSR rename, I believe you should have _CRS in your patch but you've renamed it to XCSR.
Also try to remove your XSTA rename, it should be _STA.
 
Joined
Aug 28, 2015
Messages
7
Motherboard
ASUS UX305UA (Clover)
CPU
i5-6200u
Graphics
HD 520; 1920x1080
Mobile Phone
  1. Android
Sorry for delay @starcentral .
Progress yes...and no (in the end I didn't manage to et dit to work)

In the meantime, I've applied every single patch mentioned in the VoodooI2C installation docu directly to my default DSDT and tracked each change via DiffMerge in order to derive the necessary SSDTs and ACPI Patches via config.plist. With Clover I patched the DSDT right away to get trackpad to work.

As you might have recognized already: I'm lacking the basics of ACPI patching via SSDT.




I need bascially all the patches mentioned:

1. VoodooI2C Windows 10 Patch -> SSDT-XOSI (Opencore Docu)
2. VoodooI2C I2C Controller Patch (Skylake Systems) -> SSDT-I2C-SKL ("Self made")
3. VodooI2C GPIO Controller Enable (Skylake +) -> SSDT-GPI0 (Opencore Docu)




Additionally I need GPIO Pinning -> SSDT-I2C ("Self made")
  • My Trackpads ACPI ID: ETPD. It's in the scope of _SB.PCI0-I2C1
  • I need to rename SBFI to SBFB within _CRS Method of my ETPD device & remove the "Interrupt..." paragraph
  • There's no "Name (SBFG,", neither in root, nor in _CSR method of my ETPD devide -> it's unpinned
  • The IOInteruptSpecifier of my ETPD device is 0x6d => this results in PIN 0x55
  • I have to add the "Name (SBFG..." parahraph to the root of my device and assign pin 0x55 to it.



Now fun begins:

Opencore Install Guide for Fixing Trackpads addresses both the Windows Patch (SSDT-XOSI.aml + Change _OSI to XOSI patch), as well as GPI0 Controller Enable (SSDT-GPI0.aml -> in my case GPEN = One).

With these patches + VoodooI2C.kext & VodooI2CELAN.kext installed, I can find the GPI0 device in IORegistry explorer and VodooGPIOSunrisePointLP is attached to it. That makes me confident that this should work as a basis. ETPD is listed as "ETPD@1" though and it's not underneath I2C1.

Within the scope of my ETPD Device (_SB.PCI0.I2C1.ETPD) I now need to...
  • Add "Name (SBFG,..." to the root of the device
  • Replace _CSR method with the adjusted one (SBFI rename to SBFG)
I created the following SSDT-I2C to handle this:


Code:
/*

 * Intel ACPI Component Architecture

 * AML/ASL+ Disassembler version 20180427 (64-bit version)(RM)

 * Copyright (c) 2000 - 2018 Intel Corporation

 *

 * Disassembling to non-symbolic legacy ASL operators

 *

 * Disassembly of iASL7bF6xf.aml, Wed Feb 16 21:00:25 2022

 *

 * Original Table Header:

 *     Signature        "SSDT"

 *     Length           0x000000C3 (195)

 *     Revision         0x02

 *     Checksum         0x4B

 *     OEM ID           "hack"

 *     OEM Table ID     "ETPD"

 *     OEM Revision     0x00000000 (0)

 *     Compiler ID      "INTL"

 *     Compiler Version 0x20180427 (538444839)

 */

DefinitionBlock ("", "SSDT", 2, "hack", "ETPD", 0x00000000)

{

    External (_SB_.PCI0.I2C1.ETPD, DeviceObj)    // (from opcode)



    Scope (_SB.PCI0.I2C1.ETPD)

    {

        Name (SBFG, ResourceTemplate ()

        {

            GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,

                "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,

                )

                {   // Pin list

                    0x0055

                }

        })

        Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings

        {

            Name (SBFB, ResourceTemplate ()

            {

                I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,

                    AddressingMode7Bit, "\\_SB.PCI0.I2C1",

                    0x00, ResourceConsumer, , Exclusive,

                    )

            })

            Return (ConcatenateResTemplate (SBFB, SBFG))

        }

    }

}

the Skylake I2C controller patch I will leave out for the time being.

Now the questions part:

SSDTs contained in OC/ACPI are loaded "on top" to the firmware DSDT as far as I undertood.
Hence I would assume that the paragraph "Name (SBFG.." is simply added to the scope of (_SB.PCI0.I2C1.ETPD).
It was missing in my DSDT before and is now added via SSDT.

The _CSR method is already contained in my DSDT. This needs to be replaced with the one, I put inside the SSDT-I2C, doesn't it?

My understanding is, that I have to add a patch to the config.plist that renames the _CSR method in my DSDT (usually to XCSR) in order to somehow comment it out while the changed _CSR method is loaded via SSDT.
  1. is that correct in general?
  2. do renaming patches only apply to the original DSDT (=they are not applied to any SSDT / DSDT contained in OC/ACPI)?
  3. how do I make sure to only rename that specific method within the context of the desired device
    • Opencore plist contains a string-type "Base" argument within each patch. I've seen something like this in it: \_SB.PCI0.I2C1.ETPD
    • For other patches it seems that the specification might be contained in the "find" / "replace" arguments
  4. the SSDTs contain (several) "External"-statements. what needs to be referenced there despite the Deviceobject?
_OSI to XOSI renaming looks streight away in my config.plist (5F4F5349 to 584F5349).

Thanks a lot for your time and patience!
 
Last edited:
Top