Can't get button clicks working with RMII2C

[voodoosmbus]

Can't get button clicks working with RMII2C

[1Revenger1]

Hrm, that's the second time I've seen function F3A - I'm pretty sure that what is handles your buttons. There's no documentation about it anywhere - I could try to reverse it but that is harder and I have no guarantees about how well it'd work. Would you mind if I gave you a version which logged more info about F3A?

Also I have no clue about the cursor tracking being less accurate, it's pretty accurate atleast over SMBus. I do know that I don't apply a lot of the properties for the trackpad like VoodooI2C does I think, so maybe trying to bring over some of those properties might help?

Edit: Btw dmesg does tend to work the best for getting early boot logs - but it does have a max buffer size so if you use the trackpad before you get logs, it does tend to just fill dmesg with logs about F12 packets lol. So you generally want to do it as soon as you login.

[RayPowell]

Sure, I'll try the F3A logger. If F3A is the button function, I wonder how clicks are being registered using voodooI2C / voodooI2CHID (sans RMI)?

[1Revenger1]

Microsoft's HID protocol is different, so my guess is that the sensor can just respond to both types of calls (and would only respond to one protocol once you start building it up on that protocol and initializing it). Could be interesting to see if you could mix HID and RMI4 calls though.

Edit: I can get a copy tomorrow morning btw.

[RayPowell]

People seem to have had better luck with the VoodooSMBus / VoodooRMI combo. I've had trouble finding many successful implementations of RMII2C on github.
I know that SMBus was disabled in the attached debug zip, but having looked at my config, do you see any reason why I couldn't get voodooRMI to work with voodooSMBus? According to https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Yoga_(Gen_4) and linux-hardware dumps, the touchpad is attached to both smbus and I2C, so it should work in theory.

Do you think trying to get it working with smbus would be a better route? Or would RMI likely not recognize the button clicks with SMBus either?

[1Revenger1]

Behaviour of the button I don't think would change over SMBus. That's weird it didn't work over SMBus though, do you have a log from when you tried to load it (VoodooRMI) over SMBus? If you have ApplePCISMBus or whatever loading and attaching to the SMBus controller, that would cause issues (that can be worked around).

[RayPowell]

VoodooSMBus is getting injected, and I can see it attached in IOReg. VoodooRMI and RMISMBus show up in kextstat, but not in IOreg. I got VoodooSMBusIntelLpssI2C to attach to I2C1 (where the touchpad normally is) by changing VoodooSMBusIntelLpssI2C / IOPCIMATCH to 0x9de98086 in the VoodooSMBus info.plist. Also, I don't see any trace of VoodooInput.

dmesg shows various smbus errors:

VRMI - Error: Error: Failed to read SMBus version. Code: 0xFFFFFFF0
Error: SMBus is busy, can't use it! (41)

logs / configs attached

rmi-smbus-log.zip

[RayPowell]

Based on the few repos I've seen for newer thinkpads, it seems it might be indicative of some change Lenovo made starting with the 2019 models, as X1C6 and earlier don't seem to have these issues. These might have some relevant info, since the x1 carbon 7 and x1 yoga 4 are essentially the same:

https://jcs.org/2019/07/28/ihidev
https://blog.rcarz.net/2019/09/08/linux-on-thinkpad-x1-carbon-7th-gen/

[1Revenger1]

https://github.com/VoodooSMBus/VoodooRMI/tree/F3A Do you mind trying VoodooRMI from this branch? Should be able to click the green checkmark next to the commit and download the artifacts from Github Actions, so you shouldn't need to compile yourself.

Let me get you a version of VoodooSMBus to test out as well, it shouldn't be saying that it's busy.
I did notice that it seemed like the 7 series of the carbon were changed around 2019, it's weird.

Edit: Can you send SSDT-SBUS.aml btw?

[1Revenger1]

Here's VoodooSMBus: https://github.com/1Revenger1/VoodooSMBus/runs/1140986141
Sorry, am on Big Sur right now and I don't actually know if binaries made in XCode 12/BS work in Catalina

[RayPowell]

No luck so far with the new RMI & SMbus combo. Still the same errors in log. I did notice that the smbus errors are usually between AppleSmartBatteryManager and/or PMRD messages. Correlated?
Is there anything in my config that might be causing issues with smbus - like the XOSI patch or something?

logs & SSDT-SBUS.aml attached
new_RMI-SMBUS_logs.zip

I'll try the new RMI f3A branch with I2C to check the F3A logging

[RayPowell]

Logging F3A with RMI & RMII2C. With a single button press, F3A gives DataReg: 0 on button press down and DataReg: 4 on button release. Same result with thumb clicks, multi-fingers etc...

$ log stream | grep -i voodoormi
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 61 WX: 5 WY: 3 FingerType: 0 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 61 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 62 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 62 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 62 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 62 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (241, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 65 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (240, 125) [Z: 65 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 65 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 65 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (239, 125) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 64 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (238, 126) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (237, 127) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (237, 127) [Z: 63 WX: 5 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (237, 127) [Z: 61 WX: 4 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (237, 127) [Z: 61 WX: 4 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 0
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (237, 127) [Z: 54 WX: 3 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Debug: F12 Packet
VRMI - Debug: Finger num: 0 (237, 127) [Z: 54 WX: 3 WY: 3 FingerType: 2 Pressure : 0 Button: 0]
VRMI - Info: F3A Attention! DataReg: 4
VRMI - Debug: F12 Packet
VRMI - Debug: F12 Packet
VRMI - Debug: F12 Packet
VRMI - Debug: F12 Packet
.......

[1Revenger1]

Thanks! Looks easy enough to deal with F3A I guess. Do you mind getting logs from VoodooRMI initializing as well? There should be data about all the functions including versions and stuff. Additionally, is your trackpad a clickpad which clicks down? Or is there more than one button? I can take a closer look at the logs in the morning.

[RayPowell]

The touchpad has no separate physical buttons - it's just one surface which you press down on to click. (not counting the three trackpoint buttons directly above the touchpad, which also aren't working atm...)

https://icdn1.digitaltrends.com/image/lenovo-thinkpad-x1-yoga_4-1500x1000.jpg

some RMI init logs:

debug_init.zip

[1Revenger1]

Does the trackpoint work? I wonder if the trackpoint works over PS2 (with no passthrough the RMI sensor). I've most often seen the trackpoint buttons sent in the trackpoint mouse packets. And it looks like F3A is just for buttons as the Data register is no where big enough to be publishing dx/dy for the trackpoint.

Looking at your logs, F3A has an entire registry page to itself so I have no idea how big the Query register is - but both F19 and F30 (other button registers) have query register lengths of 2.
CMD is not used, Data is 1 byte long, CTRL is 6 bytes long. (A register being a byte long).
I'm gonna try dumping the contents of CTRL and QRY with this next commit in the same branch. It should be pushed now, if you want to get the latest build from the F3A branch.

Edit: And for your SMBus issues, maybe try without SSDT-SBUS? Apple's SMBus stuff could be trying to attach, and leaving the controller in an unknown state.

[zhen-zen]

After failing to get voodooRMI to work via SMBus, I finally got voodooRMI to load by injection with voodooI2C and RMII2C - but button clicks aren't working. Also, cursor tracking / velocity scaling is noticeably less accurate than it is under the already-janky I2C / I2CHID. Clearly I'm doing something wrong.

Via dmesg or log-grepping VRMI, I can see F12 packet activity and can move the cursor, but button clicks aren't being recognized. They aren't being registered by the system and the logs always show "button: 0". Using 'tap to click', tap-clicks are registered by the system, but still appear as "button: 0" in all logs.

(The button-clicks are recognized under VoodooI2C / VoodooI2CHID (without voodooRMI))

Specs:

• Thinkpad X1 Yoga 4th gen, model 20QFCTO1WW (same model/config as https://linux-hardware.org/index.php?probe=7c5b2d05ae)
• Touchpad id: SYNA8004 / TM3467-010
• OpenCore 0.60 debug
• VoodooRMI 1.1 debug
• VoodooI2C 2.4.4

Relevant log / config info is attached. Any help would be greatly appreciated.

debug.zip

Actually the RMI over I2C (capsulated in HID packet) transport is not officially supported. It's another mode different from PTP. The latter one is calibrated according to https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/ptp-hardware-requirements-and-vendor-information. You should have the same experience with linux in this mode. (VoodooI2CHID is actually PTP over I2C-HID). And currently there's no docs on F12 mode under RMI mode, which may provide details to improve the experience.

[RayPowell]

@1Revenger1 :
The trackpoint works in Windows, but i haven't tried getting it to work on mac yet. I've been focused on fixing the touchpad, so the trackpoint is lower on the priority list. The touchscreen works when I use voodooI2CHID though. (Thought I'd throw another input device into the mix in case this wasn't confusing enough :) )

I tried VoodooSMBus + VoodooRMI without the SSDT-SBUS.aml and without the XOSI and MCHC patches. No difference. Same results as before - VoodooSMBus loads and shows up in IOreg; VoodooRMI & RMISMBUS show up in kextstat but not in IOreg; no sign of VoodooInput anywhere; same SMBus error messages: VRMI error - failed to read SMBus version ; SMBus is busy, can't use it etc...

I'm not sure what the problem is.

Haha, I should also mention that I'm not a developer or programmer or anything, so all the CTRL / QRY / register stuff is a little beyond me - but I'm willing to learn. Anyway, here's a dmesg log from the newest F3A branch build.

dmesg-RMI-F3A-2.txt.zip

[RayPowell]

@zhen-zen :
So what's the best course of action for x1y4 / x1c7 users if they want a good touchpad experience under macOS (or Linux)?

[1Revenger1]

I just pushed a version which should work. Button detection likely isn't right though - but I'll need more trackpads with F3A to iron it out.

[RayPowell]

Nice. Basic clicks are being recognized with the newest F3A build. Definite progress! Great job! However there are a lot of missed clicks. It seems to have a much harder time with thumb clicks or two-finger right-clicks. So click-wise, it's behaving pretty similarly to voodooI2CHID, but cursor movement is still much jerkier with RMI for whatever reason. Maybe it's due to all the logging of the debug version?

I'm still trying to get RMI running via SMBus, to see if it works any better.

[1Revenger1]

That's so weird. What happens if you set legacy mode in the info.plist for RMII2C to true?

[RayPowell]

No noticeable difference wth Legacy on. Maybe clicking and dragging seemed a little smoother for a second - but not a major improvement. What's weird is that (regardless of the Legacy setting) it fluctuates from short bursts of normal responsiveness to (more often) jerky movement and missed button clicks. The constant is that anything more involved than a single-finger click is a no-go, which is a bummer because I usually click with my thumb.

[1Revenger1]

Have you tried using something like Better Touch Tool's live view to see what macOS sees?

[RayPowell]

The main thing I noticed from the BTT 'live view' is that fingers and clicks tend to get stuck, like it senses fingers on the touchpad after I've removed them. That happens whether I'm using RMII2C or I2CHID though, so it might be an issue with voodooI2C or VoodooInput or something.

[1Revenger1]

hrmm, so a zero packet isn't being sent then? Fingers seemed to be at the right places and stuff though when moving them around? That's so weird

[RayPowell]

Yeah in live view the location/placement of my fingers is accurate. The main problem is clicking. I just tested the laptop on Linux and the touchpad functions perfectly - far better than on Windows, in fact - so that rules out hardware problems and completely points to a problem with my current hackintosh config.

I'd really like to see if I fare any better with a working RMISMBus and voodooI2C out of the equation.
Should I file a separate issue on my voodooSMBus problems, or keep it in this thread, as it's really more to do with RMI accessing SMBus? Again, I really appreciate the help. :)

[1Revenger1]

I'm the one mostly working on VoodooSMBus for now, so staying here is fine. Have you guys actually gone into Linux and confirmed it works over SMBus? It does specify that a firmware update can help on the arch wiki page, which you could probably do using a Linux USB without installing. I'd check your ACPI patches to I guess and make sure they aren't messing with SMBus.

For testing the lag, does the same lag occur in recovery? What happens if you try booting with the minimum needed kexts to boot macOS?
Edit: Oh, I'm seeing some things like Fake DMAC, Fake PMCR, Fake MCHC, and Fake PWRB, do those help in any way?

[RayPowell]

I checked the touchpad firmware and it's on the latest version. It must have been updated before I got the computer in July.

Sorry if I was unclear - the touchpad is running on I2C in Linux, not SMBus. The Arch wiki https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Yoga_(Gen_4) says the touchpad modules are 'psmouse, rmi_smbus, i2c_i801' though.
Actually, I get the same SMBus errors in Linux as I do on mac, so there's obviously something strange going on.

dmesg:

---

[ 0.866729] i801_smbus 0000:00:1f.4: SPD Write Disable is set
[ 0.866784] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt
......
[ 0.897340] i2c_hid i2c-SYNA8004:00: supply vdd not found, using dummy regulator
[ 0.897355] i2c_hid i2c-SYNA8004:00: supply vddl not found, using dummy regulator
[ 1.053414] input: SYNA8004:00 06CB:CD8B Mouse as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-SYNA8004:00/0018:06CB:CD8B.0001/input/input6
[ 1.053543] input: SYNA8004:00 06CB:CD8B Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-SYNA8004:00/0018:06CB:CD8B.0001/input/input7
[ 1.053602] hid-generic 0018:06CB:CD8B.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA8004:00 06CB:CD8B] on i2c-SYNA8004:00
[ 1.072853] i801_smbus 0000:00:1f.4: Timeout waiting for interrupt!
[ 1.072854] i801_smbus 0000:00:1f.4: Transaction timeout
[ 1.076878] i801_smbus 0000:00:1f.4: Failed terminating the transaction
[ 1.077122] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!

---

(there were some ethernet device messages before the smbus timeout so i bios-disabled the ethernet and re-ran dmesg, but the smbus errors persisted)

I did a full hw-probe you can check out https://linux-hardware.org/?probe=1364f0c7fa
(I've also disabled a bunch of other hardware via the bios, like TB3/usb-C, bluetooth, camera etc..., which is reflected in the hw-probe.) I don't have much experience with Linux, so my troubleshooting knowledge there is pretty limited. Is there anything else I should check?

.....

I re-tested the touchpad in Recovery and there's an interesting new development: now the screen glitches out when I press down on the touchpad. It didn't used to do that. I'm not sure what change brought that on. At least the glitching is only in Recovery mode, not regular macOS / linux / win.

I also disabled the DMAC, PMCR, and PWRB patches (after the Recovery glitch thing), and haven't been able to tell much of a difference. They're likely leftovers from the x1c6 / x1c7 repos I was initially using as reference.
But I'm definitely suspicious there's something awry in my configuration.
Now to double check voodooI2C... ugghhhh...

[zhen-zen]

Your input is i2c-SYNA8004 according to the probe and it seems that SMBus is not used at that time. However you can only config it to run under either i2c or SMBus mode, not simultaneously.

Can you check the "interrupt mode" property of RMII2C in ioregexplorer? And you can also try the latest Voodoo2C. However, I think polling mode won't be that terrible.

[RayPowell]

ioreg shows:
RMII2C Interrupt Mode = Pinned

When installing voodooI2C, I met the condition stated in the documentation:
"If you do not have IOInterruptSpecifiers listed as above then you are good to go and can skip straight to the section Installing the kext."
The touchpad didn't show IOInterruptSpecifiers in IOreg, so I didn't mess with any of the gpio pinning stuff outlined in the documentation, just installed as-is. Based on the fact that I've never seen any errors or messages in the log indicating a problem with voodooI2C/gpio/voodooInput, I can only assume it is configured correctly (?). However, going by the actual performance of the touchpad - all the missed button clicks and the inability to perform most gestures, I'd say something is wrong, and I'm kinda stumped as to how to fix it. The same applies when using voodooI2CHID rather than RMI. So I should try switching to polling mode?

edit: I've built all the applicable kexts with the latest commits. No changes to report.

[zhen-zen]

So yours should be woking with native GPIO interrupt on I2C mode. I'm afraid polling mode won't do any better. Theoretically you should have similar experience with VoodooI2CHID since Linux also use i2c-hid. However I have no idea why it's not as good.

Maybe same with #69 ?

[1Revenger1]

This is probably a better issue to track laggy trackpad. Either that or create a new issue. #69 seems dead. I think it's related to configuration as well because I have an X1 Extreme and it's 100% fine.

[RayPowell]

Despite the shared series name, doesn't the X1 Extreme have significantly different internals/hardware than the X1 Carbon or Yoga?

If by "lag" you mean general cursor jitter/resistance/inaccuracy/jerkiness, then I have lag. I'm not experiencing a latency issue though, if that's what you're referring to. It's more like drag than lag.

It became easier to pinpoint the exact problems with the internal touchpad when I hooked up the Magic Trackpad 2 and compared the two in the BetterTouchTool live view. Using the Magic Trackpad 2 as the gold-standard reference, the main issues with the internal trackpad + Voodoo kexts are:

• Frequent lack of thumb rejection -->
• Input "sticking" after fingers have been removed, causing the next input/click/gesture to go unrecognized - most pronounced with a resting thumb. It's particularly bad with thumb double-clicks - the second click almost never registers. With the Magic Trackpad, you can click rapidly and repeatedly with the thumb, never lifting it, and every single click is registered.
• Inconsistent cursor velocity scaling (if that's the correct term ?). For instance, there's far more resistance when moving the cursor upward than downward / two-finger-scrolling upward vs. downward.
• Two-finger-scrolling frequently drops out. I've noticed this more with the latest 2.5.2 voodooI2C.
• It takes multiple attempts for a pinch-to-zoom to register, if it ever does at all.

(that's with VoodooI2C + VoodooI2CHID)

These issues aren't constantly present, more like 75% of the time. Definitely enough to be incredibly frustrating. I would just chalk it up to subpar Synaptics hardware, but again - it works fine in Linux (and Windows, to a lesser extent).

It's too bad there aren't many X1 Carbon 7 or X1 Yoga 4 hackintosh installs out in the wild yet, because it would definitely be helpful to see if this is purely an isolated issue, or a common thing with 2019+ Carbons / Yogas. I'm sure more will start popping up in the next year or two. And hopefully they'll have the same problem haha.

[1Revenger1]

Moved to: #84
Some things like thumb rejection should be better now though