[VoodooI2CHID] Fixing Physical Buttons on Trackpad

[Maleficent-Magik]

So, after updating Kexts... the trackpad works!

CONNEXION : #4 #3

[Qonfused]

Does it work with gestures or just as a ps2 mouse (right/left click only)? You can try a two-finger scroll in a browser or try zooming in on an image with a pinch in Preview.

It does make sense that updating OpenCore + Kexts though should fix some instability. OpenCore versions 0.7.8 to 0.8.2 should be mostly the same; if you want to boot Ventura, you'll also need OpenCore 0.8.3 and Lilu 1.6.2.

Edit: I still do expect to have to modify some of the custom GPI0 polling/related Voodoo kexts to make sure they're pointing to the correct device names/etc.

[Maleficent-Magik]

About the trackpad:

Gesture:

3 fingers: open the window manager & search with Siri
2 fingers: up & down

Does not work:

2 fingers: secondary click

Touch:

Approximately OK... but I have the impression that if we touch the touch, we will have to use the touch forever until the reboot of the PC..... we would be potentially obliged to reboot the pc to get back the hand on the trackpad...

[Maleficent-Magik]

It does make sense that updating OpenCore + Kexts though should fix some instability. OpenCore versions 0.7.8 to 0.8.2 should be mostly the same; if you want to boot Ventura, you'll also need OpenCore 0.8.3 and Lilu 1.6.2.

So I already managed to get started on Monterey thanks to you, I'm not going to take a chance by screwing up in Ventura heh... 😂 😂

[Qonfused]

So far I've updated these kexts in the #update-opencore-config branch. Some things to note is that IOElectrify.kext and USBInjectAll.kext aren't needed (they're already disabled in your config though).

[Maleficent-Magik]

Oh I hadn't noticed, thank you!

[Qonfused]

I wasn't able to reproduce the same behavior after updating all the kexts, though I may need to re-test that after I reverted that commit by mistake (I don't recall whether I actually updated the Voodoo kexts at that point, though I recall testing without updating them).

I did note that VoodooI2C and VoodooI2CHID are both used for the trackpad and touchscreen, and VoodooPS2 is used only for the keyboard. I didn't see the VoodooI2CHID-AsTouchscreen.kext or the VoodooI2CHID-AsTouchscreen.kext loaded in my config (or the original config). I'm not sure what their purpose is; they're likely artifacts from previous testing.

I'm assuming that loading the root kext should be done before loading any of it's plugins, so there may be an improper loading order in my config. Below is a table of their index (only the order matters) and some relevant entry properties, shortened for brevity:

Idx	Source Kext	Executable	Kext Plugin	Enabled
34	VoodooI2C.kext	Contents/MacOS/VoodooGPIO	VoodooGPIO.kext	Yes
35	VoodooI2C.kext	Contents/MacOS/VoodooI2CServices	VoodooI2CServices	Yes
36	VoodooI2C.kext	Contents/MacOS/VoodooInput	VoodooInput.kext	Yes
37	VoodooI2C.kext	Contents/MacOS/VoodooI2C		Yes
38	VoodooI2CHID.kext	Contents/MacOS/VoodooI2CHID		Yes
39	VoodooPS2Controller	Contents/MacOS/VoodooPS2Controller		Yes
40	VoodooPS2Controller	Contents/Plugins/VoodooPS2Keyboard	VoodooPS2Keyboard.kext	Yes
41	VoodooPS2Controller	Contents/Plugins/VoodooPS2Mouse	VoodooPS2Mouse.kext	No
42	VoodooPS2Controller	Contents/Plugins/VoodooPS2Trackpad	VoodooPS2Trackpad.kext	No
43	VoodooPS2Controller	Contents/Plugins/VoodooInput	VoodooPS2Input.kext	No

I figure this is caused by some fixes for power-optimization (e.g. GPIO pinning for the trackpad and touchscreen). In #7 I'll try to figure out which of those ACPI patches are might be interfering or are simply incompatible. I do notice an error mentioning AddressingMode7Bit and I2C1 or something along those lines, which are indicative of some kind of GPIO pinning recognizable from the voodoo guide. There may be an SSDT to enable it that isn't routed to the proper device, though I noticed that the pro-duo shares the same device-id for the trackpad so I'm not sure.

[Maleficent-Magik]

Missclick* (thanks to Google Chrome who scrolled down my page and clicked at the same time... my apologies)

[Qonfused]

Huh, seems there is a guide for fixing the GPI0 device in the ACPI patching section of the guide here. If applicable, I'll diff my changes from what may already be implemented, but I'd have to verify that the device is working correctly before any additional GPI0-related ACPI patches can get loaded.

Will have to wait until tomorrow to have time to work on that, but it is a much easier process than I imagined (and hopefully that's the issue if the device works fine when it works).

[Qonfused]

Noticing in #10 that the left click button maps to right click, and the right click button maps to middle click.

GPI0 device is working correctly.

[Qonfused]

There is some conflict that prevents touchscreen from working several seconds after startup, even with the -vi2c-force-polling boot arg. Not a new issue, but one I didn't expect to persist.

Otherwise the trackpad (excluding the physical buttons) and touchscreen for both displays work as expected.

[Maleficent-Magik]

There is some conflict that prevents touchscreen from working several seconds after startup,

A few seconds is fine... Worse would have been if it had been blocked for a long time...

(This title is better... better explained than the old title...)

[Qonfused]

Sorry I meant *after several seconds; it can occasionally happen (albeit much later) to the trackpad I've noticed, but both are resolved after closing the lid for a few seconds.

[Qonfused]

Moved touchscreen issue to #12.

[Maleficent-Magik]

In looking on Issues about Karabiner, i'have found the SAME problem about we, Karabiner-Element Issues 2370

So, we need just to edit karabiner.json with that :

"simple_modifications": [
  {
    "from": {
      "pointing_button": "button2"
    },
    "to": {
      "pointing_button": "button1"
    }
  },
  {
    "from": {
      "pointing_button": "button1"
    },
    "to": {
      "pointing_button": "button2"
    }
  }
]

Originally posted by @kirintwn in pqrs-org/Karabiner-Elements#2370 (comment)

[Qonfused]

Managed to fix the buttons with a reorder of kext plugins and adding voodoops2trackpad + voodooinput in 0b67115. I downgraded voodoo kext versions as part of this, but the same fix as proposed above should be applied when updating to newer versions.

[Qonfused]

PR merge on Jul 22 seems to address this issue: VoodooI2C/VoodooI2C@9ab9831

Update VoodooI2C Satellites and support for physical buttons (VoodooI2C/VoodooI2C#514)

1. Always pass buttons as pressure on single-button touchpads (fix Right click using click on bottom right doesn't work anymore  VoodooI2C/VoodooI2C#496)
2. Always disable Force Touch and pass buttons to buttons device on touchpads with two physical buttons (fixes inability to click without finger on the touchpad (In Recovery clicking with separate physical button requires a finger to be on the touchpad VoodooI2C/VoodooI2C#499) and inability to use the right button with default settings)
3. Disable Force Touch on all touchpads if tap to click is disabled (fixes inability to make a non-force click with default settings, especially in Recovery where there is no System Preferences application)

• NULL -> nullptr, FALSE -> false

• Update VoodooI2CAtmelMXT

• Update VoodooI2CHID

Co-authored-by: Michael Belyaev [email protected]

[Maleficent-Magik]

Managed to fix the buttons with a reorder of kext plugins and adding voodoops2trackpad + voodooinput in 0b67115. I downgraded voodoo kext versions as part of this, but the same fix as proposed above should be applied when updating to newer versions.

I need to try so 🤔... I will try this night (actually 7AM)

If this can be resolve, it's good

[Qonfused]

I have noticed an interesting quirk where both physical buttons are aligned to the top-left position (0,0). I believe this is due to the one-button mode (or at least the implementation) since this is supposed to be for trackpads that click based on an under-device actuator, which wouldn't need to report a new finger position for the button (as you still have a finger on the trackpad when clicking). Having the physical buttons pressed would only register as a new finger position (at 0,0) when all other fingers are released, which is only problematic when trying to click and drag using one of these buttons.

Here's a video of how this looks like using FingerMgmt:

Screen_Recording_2023-02-25_at_6.14.59_AM.mov

[Qonfused]

Relevant line:
https://github.com/VoodooI2C/VoodooI2C/blob/17a5f58227a164b426011fd077a5c549766474b3/Multitouch%20Support/Native/VoodooI2CNativeEngine.cpp#L51

// if it has secondary button, then it will be passed as buttons on the "trackpoint" device

This is what I thought sets the button x,y positions to 0,0:

// Commit: https://github.com/VoodooI2C/VoodooI2C/commit/9ab98319b6411c4a4822cc12f840df85cc684bfc
// Mutitouch Support/Native/VoodooI2CNativeEngine.cpp#LN96-103
96  | if (firstTransducer->has_secondary_button) {
97  |     RelativePointerEvent event;
98  |     event.dx = 0;
99  |     event.dy = 0;
100 |     event.buttons = firstTransducer->physical_button.value();
101 |     event.timestamp = timestamp;
102 |     super::messageClient(kIOMessageVoodooTrackpointRelativePointer, voodooInputInstance, &event, sizeof(event));
103 | }

Both physical buttons only modify the current finger's pressure to left-click when force touch is enabled in system preferences; they don't function as standalone buttons with this setting enabled. This is relevant as the relevant logic is within/after the if statement:

// Commit: https://github.com/VoodooI2C/VoodooI2C/commit/9ab98319b6411c4a4822cc12f840df85cc684bfc
// Mutitouch Support/Native/VoodooI2CNativeEngine.cpp#LN94
94  | if (firstTransducer->physical_button.value() != firstTransducer->physical_button.last.value && !isForceClickEnabled()) {

These same issues are mentioned in these discussions:

• Support secondary button VoodooI2C/VoodooI2C#445 (comment)
• acidanthera/VoodooInput@a1e92d7#commitcomment-48777900

[Qonfused]

Currently collecting details for a new VoodooI2C issue (gist): https://gist.github.com/Qonfused/2191a1adf4e46f7cfb61c82938a26361

[Maleficent-Magik]

Thanks for creating it, I had started to look at creating an Issue, but you did it x)

To see the continuation...

[1Revenger1]

https://github.com/torvalds/linux/blob/master/drivers/input/mouse/elan_i2c_core.c#L1005
Seems like a fairly simple change. Just have to read a few more bits from the tp_info details.
https://github.com/VoodooI2C/VoodooI2CELAN/blob/3cb69b61fc4dc4eab127787455d0f1c337a3df0c/VoodooI2CELAN/VoodooI2CELANTouchpadDriver.cpp#L236
Current driver assumes that all trackpads are clickpad, which seems to generally hold for most I2C trackpads.

Edit: Actually, am a bit confused. Does the right click button work at all, or does it act as a left click?

[Qonfused]

Interesting references, I'll take a closer look there. Though this is a newer ELAN trackpad that uses the precision touchpad protocol; I had avoided using the ELAN driver based on that mention here: https://github.com/VoodooI2C/VoodooI2CELAN#supported-touchpads.

The right button works but only as left click after VoodooI2C/VoodooI2C#445. Previously it wasn't working at all, only the left button was.

[1Revenger1]

Ah, I understand. I unfortunately am much less knowledgeable with VI2CHID

[Maleficent-Magik]

First of all, thank you very much for taking the time to write @1Revenger1, it was really a chance to mention you ^^', I didn't think you would answer to tell you everything....

Just a question, do you know someone who would be more qualified on I2CHID? if we can't solve the problem...

[Qonfused]

I'll look at refactoring the transducer button reporting, though it might be hard to identify a clean fix for a PR. It's not clear what edge cases are being handled in the current implementation.

[Qonfused]

^^ You can subscribe to notifications in the linked issue.

[Maleficent-Magik]

Using the latest version of the Qonfused EFI, I noticed that VoodooInput spams this a lot in kernel-logs:

[...]
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
2023-03-26 18:28:19.37 kernel[0]: (VoodooInput) <compose failure [UUID]>
[...]

also, this regarding AppleSmartBatteryManager, I wonder if there is not a problem with the battery management in macOS? :

"2023-03-26 18:28:07.72 kernel[0]: (AppleSmartBatteryManager) Failed to read shutdown data error flags"

"2023-03-26 18:28:14.36 kernel[0]: (AppleSmartBatteryManager) Failed to read keyInfo . rc:0x84
2023-03-26 18:28:14.36 kernel[0]: (AppleSmartBatteryManager) SMC Key is not supported."

[1Revenger1]

The log command can be quite useless. The compose failure is errors from trying to print the logs. I usually just use sudo dmesg nowadays.

If the debug version of VoodooInput is being used, it does log each packet being sent.

[Qonfused]

The <compose failure [UUID]> lines are an issue with Apple's logging (acidanthera/bugtracker#1148). I filter those lines out explicitly in my debug script when pulling logs from syslog; it's a strange issue but they're safe to ignore.

I think the first AppleSmartBatteryManager message is indicating a rtc/shutdown issue. It's probably related to any startup dialogs like 'you shut down your computer because of problem'. Not sure how the latter messages are emitted though.

[Maleficent-Magik]

This issue can be marked as Resolved by @1Revenger1 !

VoodooI2CHID.kext.zip

Everything is correctly attributed! The left click is the left click, the right click is the right click.

A solved issue! Thank you!

[Maleficent-Magik]

Closed. Free to reopen this issue.

[Qonfused]

There's also the VoodooI2C/VoodooI2C#527 issue for tracking. Until VoodooI2C/VoodooI2CHID#70 is merged, I'll keep this open with the other issue for consistency and to address any regressions.

[Qonfused]

For now, I'll vendor the built kext with 109fcd5. You can find the latest oce-build from that commit here.

[Qonfused]

Fixed in VoodooI2C/VoodooI2CHID@9ebbc8f. Thanks @1Revenger1 and @UsedDiscord!