-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix VoodooI2C intermittency issue with I2C polling #24
Comments
VoodooI2C should only check the return values for the _CRS and _DSM methods, which made investigating this issue quite strange. The declarations for I've included this fix in 6f50e2b. It's not clear what behavior this may cause in windows, so it's possible for this to create a regression if enabled on windows. For now, the override will only be applied for macOS. Update: This does not appear to resolve this issue, though this may fix some behavior since the default bus speed values are taken from Broadwell and aren't generally compatible with CFL/CML. The same eventual intermittency issue (devices eventually disabling themselves) persists, though this can result in neither touch screen working. I had figured that other I2C controllers may be interfering, though the only other controller in IOReg would be I2C@2 ( Reverting this change in |
Replacing GPIO's I don't know what behavior this changes, as VoodooI2C/VoodooI2CHID doesn't appear to depend on a specific _HID value, although a lot of reference working OEM GPIO implementations fall back to this _HID value; ASUS commonly has buggy GPIO that is setup like this. Update: This does not appear to have an effect on GPIO behavior in macOS or with VoodooGPIO. |
Voodoo seems unable to retrieve anything from _DSM/XDSM methods, which is problematic. Noticed that when checking the trackpad's _DSM method, VoodooI2CHID emits this error message: This is invoked by this function:
|
GPIO pinning doesn't look to be a viable workaround here. Using
I used the below table to calculate the GPIO IRQ values (as well as the CannonLake table from CoreBoot, mentioned in #19 (comment)): GPIO Calculation Table - (Intel 8 Gen) CoffeeLake-LF and Whiskylake CPUs
The GPIO device is correctly enabled, and the trackpad is correctly enabled and configured for GPIO pinning. It seems that these pins (including the common pins I mentioned earlier) are locked somehow. There doesn't appear to be a mechanism to reset pin ownership if this is can be resolved in macOS, and neither does there appear to be a legacy GPIO setting in BIOS. I found a comment from gvtk that seems to encounter the same issue regarding firmware support for legacy GPIO (for the UX582LV):
|
Moving on to addressing this issue under I2C polling, I also noticed that each of the 'slave address not acknowledged' errors do mention two specific I2C controllers (unique to each touch input):
^^ These however use the same serial address
|
I've done some pre-emptive work to address the duplicate To investigate a possible I2C/GPIO resource conflict, I've compiled a list of occupied serial addresses in DSDT order:
Important notes:
|
After revisiting the GPIO pinning guide, there is more to this; there is a mismatch between the hardware pin and GPIO pin number (which is expected). This can be corrected based on values from this table. E.g. in the case of the trackpad: CNL_GPP(/* GPP_D */ // Match based on pad group (e.g. GPP_D13 is group D)
0, // num
68, // base // then subtract the base from the GPIO pin
92, // end
96, // gpio_base // now add the gpio_base to this value:
), // (81) => 81 -68 +96 = 109 (0x6d) Now for the trackpad + touchscreen inputs:
This doesn't resolve the GPIO pinning issue mentioned in the previous comment, but these would be the correct pins. |
In VoodooI2C/VoodooI2C#321 (comment), @jjsmith92 addressed the fix for Linux for the issue of TrackPad stopping working after a period of use; however, the file he uploaded was expired. Someone needs to re-porting the Linux fix to VoodooI2C. |
I believe these are all the related patches that he must have implemented: https://bugzilla.kernel.org/show_bug.cgi?id=200663
|
@Qonfused Would it be possible to port the numpad driver from Linux? |
It would need to be refactored, though all it does is convert x/y positions on the trackpad to the corresponding digits; you could do this in linux/macOS without polling the I2C driver either. There may be a way through some sort of VoodooI2CHID interface class (e.g. multitouch) that lets you get the finger position on the trackpad. I'm not too familiar with how VoodooI2C's interface drivers/etc work on these trackpads but I imagine that'd be the best way to do so. |
Can you report this back to that VoodooI2C thread? Thanks! |
Still unresolved for the ELAN1200 trackpad. That issue is a better fit for tracking in VoodooI2C/VoodooI2C#321 or in a dedicated issue. I found a workaround for the touchscreen displays on the UX481 using APIC interrupts instead. Unfortunately, the UX481 isn't as lucky to use APIC interrupts below |
Using VoodooI2C, I2C devices can stop responding intermittently until sleep (even when polling mode is forced).
Regarding interface devices like the trackpad and touchscreen displays, this also appears to be an issue affecting I2C devices with GPIO interrupts (see VoodooI2C/VoodooI2C#435). It also appears to happen with the same controllers (i.e. same pad group) on another comet lake laptop in that issue: VoodooI2C/VoodooI2C#435 (comment).
GPIO pinning may also be silently failing, falling back to I2C polling. They can still report the expected GPIO pin and report GPIO mode when instead using I2C polling. Should have been resolved as per VoodooI2C/VoodooI2C#487 but may be worth checking for regression.
Update: GPIO pinning is failing for all 3 input devices and falling back to polling mode.
voodooI2C.log
The text was updated successfully, but these errors were encountered: