Can't get button clicks working with RMII2C #63
Comments
|
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. |
|
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)? |
|
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. |
|
People seem to have had better luck with the VoodooSMBus / VoodooRMI combo. I've had trouble finding many successful implementations of RMII2C on github. 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? |
|
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). |
|
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:
logs / configs attached |
|
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://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. Edit: Can you send SSDT-SBUS.aml btw? |
|
Here's VoodooSMBus: https://github.com/1Revenger1/VoodooSMBus/runs/1140986141 |
|
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? logs & SSDT-SBUS.aml attached I'll try the new RMI f3A branch with I2C to check the F3A logging |
|
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 |
|
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. |
|
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: |
|
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. 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. |
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. |
|
@1Revenger1 : 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. |
|
@zhen-zen : |
|
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. |
|
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. |
|
That's so weird. What happens if you set legacy mode in the info.plist for RMII2C to true? |
|
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. |
|
Have you tried using something like Better Touch Tool's live view to see what macOS sees? |
|
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. |
|
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 |
|
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. |
|
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? |
|
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. dmesg: [ 0.866729] i801_smbus 0000:00:1f.4: SPD Write Disable is set (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 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. |
|
Your input is 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. |
|
ioreg shows: When installing voodooI2C, I met the condition stated in the documentation: edit: I've built all the applicable kexts with the latest commits. No changes to report. |
|
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 ? |
|
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. |
|
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:
(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. |
|
Moved to: #84 |
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:
Relevant log / config info is attached. Any help would be greatly appreciated.
debug.zip
The text was updated successfully, but these errors were encountered: