VoodooI2C Help and Support

[gvkt]

Linux people seem to have solved this problem and Windows works fine so a programmable solution exists.

I am trying to understand if this is a configuration/installation problem or a current limitation/bug of Voodoo kexts.

I will be happy if I can get a single finger mouse functionality on the screenpad for cursor movement and clicks along with multi-finger touch on main screen OR multi-finger gestures on trackpad with touch screen can even dead for touch. I don't know if people who are reporting single finger success on screenpad are compromising the multi-touch on main screen (or they don't have touch on main screen).

As I wrote earlier, I can get mouse emulation on the screenpad by removing the multi-touch section in the kext. But that does screw up the working multi-finger gestures on main screen, so essentially no multi-finger on either. That is a crippled solution.

 

[sqlsec]

Linux people seem to have solved this problem and Windows works fine so a programmable solution exists.

I am trying to understand if this is a configuration/installation problem or a current limitation/bug of Voodoo kexts.

I will be happy if I can get a single finger mouse functionality on the screenpad for cursor movement and clicks along with multi-finger touch on main screen OR multi-finger gestures on trackpad with touch screen can even dead for touch. I don't know if people who are reporting single finger success on screenpad are compromising the multi-touch on main screen (or they don't have touch on main screen).

As I wrote earlier, I can get mouse emulation on the screenpad by removing the multi-touch section in the kext. But that does screw up the working multi-finger gestures on main screen, so essentially no multi-finger on either. That is a crippled solution.

Thank you for your ideas. I found this discussion about this trackpad in the Linux community at: https://bugzilla.kernel.org/show_bug.cgi?id=204991

According to this idea, I tried to use Xcode to compile the project myself. I feel that the main code is in this file https://github.com/VoodooI2C/Voodoo.../VoodooI2CPrecisionTouchpadHIDEventDriver.cpp

I tried to increase the IOSleep delay before entering the enterPrecisionTouchpadMode() function. I was too weak. I added several IOSleep, but it didn’t seem to be successful. Is it a problem with my operation? Is it still missing the reason for SET_OR_SEND_REPORT?

 

[gvkt]

@sqlsec, as I responded in the Voodoo Git forum, the delay solution has been superceded in Linux by simply disabling real time power management for Goodix devices.

Not sure Voodoo developers have much time to address our issues, so we may be on our own to develop a separate Elan/Synaptics like Satellite for Goodix borrowing from Linux driver code.

Can you please take a look and see if you can reliably find a way to insert debug messages via IOLog in the Voodoo code that you can see post-boot? For example, a message that it executes the VoodooI2CPrecisionTouchpadHIDEventDriver::enterPrecisionTouchpadMode(). I am trying to put a message near power on and on the above method to see if they are close (in timestamps) assuming the above method is even executed. But for some reason, most IOLog statements I insert aren't shown in dmesg. The only thing there is a continuous sequence of keyPressed items even when one isn't touching the trackpad.

Once we have verified the timing above and the ability to log anywhere in the code, we can check whether the trackpad is sending reports as a legacy mouse.

 

[gvkt]

For those that may have stumbled onto this thread via web search for a problem with their trackpads or touchpads which only do single finger and no multi-touch, I have found the problem with the current code in VoodooI2CHID for which there is an easy fix. The details and fix can be found at

GitHub - gvkt/VoodooI2CHID

Contribute to gvkt/VoodooI2CHID development by creating an account on GitHub.

github.com

This fix should make it into a future release of VoodooI2C. This makes the infamous Goodix GDX1515 Screenpad on ASUS laptops work properly as a trackpad with multi-touch. But the fix also applies to any trackpad or touch screen that can work in both touch screen and trackpad modes (like for example, the second screen in Zenbook Duos). The fix restores multi-touch for all such devices.

 

[sqlsec]

For those that may have stumbled onto this thread via web search for a problem with their trackpads or touchpads which only do single finger and no multi-touch, I have found the problem with the current code in VoodooI2CHID for which there is an easy fix. The details and fix can be found at

GitHub - gvkt/VoodooI2CHID

Contribute to gvkt/VoodooI2CHID development by creating an account on GitHub.

github.com

This fix should make it into a future release of VoodooI2C. This makes the infamous Goodix GDX1515 Screenpad on ASUS laptops work properly as a trackpad with multi-touch. But the fix also applies to any trackpad or touch screen that can work in both touch screen and trackpad modes (like for example, the second screen in Zenbook Duos). The fix restores multi-touch for all such devices.

CannolLake H CPU can try the following formula to calculate GPIO Pin

If APICPIN > 47 And APICPIN <= 71 Then   
    GPIOPIN = APICPIN - 16   
    GPIOPIN2 = APICPIN + 240
    If APICPIN > 47 And APICPIN <= 59 Then GPIOPIN3 = APICPIN + 304 
ElseIf APICPIN > 71 And APICPIN <= 95 Then
    GPIOPIN = APICPIN - 8   
    GPIOPIN3 = APICPIN + 152
    GPIOPIN2 = APICPIN + 120
ElseIf APICPIN > 95 And APICPIN <= 119 Then
    GPIOPIN = APICPIN       
If APICPIN > 108 And APICPIN <= 115 Then
      GPIOPIN2 = APICPIN + 20
End If

 

[gvkt]

@sqlsec, That is the same calculation as the tables in the pinning guide arrives at. I have tried all the three for my APIC interrupt specifier of 0x5F (95) for which the calculations yield 87 (0x57), 247 (0xF7) and 215 (0xD7). None of them work in that the trackpad is unresponsive. For the last two, the interrupt registration happens fine (as shown in IO Registry) but no interrupts arrive. For the first one, there is an error message in the logs "Pin 74 (0x4A) cannot be used as IRQ". 74 is the calculated hardware pin for GPIO pin 87.

The possible explanation is that the BIOS has specified APIC as the owner for that pin (74) and may have even locked it. VoodooI2C will not register for interrupts in such a case and throws that error message.

Linux people have found same ownership/locked issue in a few trackpads. Not sure they have solved that problem.
(https://bugzilla.kernel.org/show_bug.cgi?id=199911)

What is your APIC number for the trackpad?

 

[sqlsec]

@sqlsec, That is the same calculation as the tables in the pinning guide arrives at. I have tried all the three for my APIC interrupt specifier of 0x5F (95) for which the calculations yield 87 (0x57), 247 (0xF7) and 215 (0xD7). None of them work in that the trackpad is unresponsive. For the last two, the interrupt registration happens fine (as shown in IO Registry) but no interrupts arrive. For the first one, there is an error message in the logs "Pin 74 (0x4A) cannot be used as IRQ". 74 is the calculated hardware pin for GPIO pin 87.

The possible explanation is that the BIOS has specified APIC as the owner for that pin (74) and may have even locked it. VoodooI2C will not register for interrupts in such a case and throws that error message.

Linux people have found same ownership/locked issue in a few trackpads. Not sure they have solved that problem.

What is your APIC number for the trackpad?

It seems that your question is much more complicated than I thought.

 

[gvkt]

It seems that your question is much more complicated than I thought.

This is the problem in my case (from Linux on this laptop)

pin 74 (UART2_CTSB) 87:INT3450:00 GPIO 0x80900102 0x0000005f 0x00000000 [LOCKED full, ACPI]

While it is configured for GPIO, that pin is locked in ACPI mode by BIOS. So Voodoo gives up without registering on that pin. Unfortunately, this seems to be the only pin on which the trackpad sends its interrupts for GPIO pinning. I tried disabling the APIC check in Voodoo and force registration as this seems to have worked in Linux for some trackpads in the past but still don't get interrupts.

Linux works with this trackpad OOB, so there must be a workaround with the latest pin control code that may not have made it to VoodooGPIO.

So this is a bios problem rather than a goodix trackpad problem.

Can you please post your entire ETPD section in your DSDT? Want to see if my DSDT does something different. Thanks.

 

[sqlsec]

This is the problem in my case (from Linux on this laptop)

While it is configured for GPIO, that pin is locked by BIOS. So Voodoo gives up without registering on that pin. Unfortunately, this seems to be the only pin on which the trackpad sends its interrupts for GPIO pinning. I tried disabling the APIC check in Voodoo and force registration as this seems to have worked in Linux for some trackpads in the past but still don't get interrupts.

Linux works with this trackpad OOB, so there must be a workaround with the latest pin control code that may not have made it to VoodooGPIO.

So this is a bios problem rather than a goodix trackpad problem.

Can you please post your entire ETPD section in your DSDT? Want to see if my DSDT does something different. Thanks.

this is my original DSDT file

 

[Feartech]

this is my original DSDT file

please update your hardware profile to allow others to help you easier

https://www.tonymacx86.com/account/account-details

please read the faq for proper hardware profile setup:

[FAQ] READ FIRST! Laptop Frequent Questions

This is an updated FAQ from the Original Thread: https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/post-1045259 Before asking a question, many common questions are already commonly asked and answered, and many answers exist in the sticky threads in this forum...

www.tonymacx86.com