[VoodooI2CHID] Fixing Physical Buttons on Trackpad

[Maleficent-Magik]

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

CONNEXION : #4 #3

[Maleficent-Magik]

Looking into this issue again, it seems that versions 2.7+ recognize both trackpad buttons (not just the primary button).

unless I'm mistaken, the version that was when I created this issue was 2.7... https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/8#issuecomment-1221542362

I'm not sure I understand?

By the way, @gvkt talks about the ZenBook Pro, as well as @1Revenger1, I didn't have the time to look at what they really talk about, but in any case, they talk about the Zenbook...

But since you quoted the issue, you have probably already seen this

On Linux, the trackpad uses multiple drivers per the same HID device to handle the touchpad and mouse inputs as separate HID interfaces (as do the touchscreens for mouse/touchscreen/stylus inputs). It does not expose the trackpad and buttons as separate devices.

So, Trackpad + Buttons = 1 Device?

EDIT : I just saw that VoodooI2C released a new version this week, the 2.8 https://github.com/VoodooI2C/VoodooI2C/releases/download/2.8/VoodooI2C-2.8.zip

---

(I'm really sorry I can't help much... it's a bit complicated with my courses (university) that take a lot of my time. I try as I can, I doubt I'll be cited in the credits for helping you a little... If I could be cited in the credits as a little help since a little bit the departure of this repo, I would thank you very much)

[Qonfused]

I believe it was also version 2.7 that I used when I (very briefly) reported success. The prior version was 2.6.5 (which is actually the previous release) so I was curious what changes were made that aided in the physical buttons being detected.

Yeah the trackpad itself works as a single device using the same I2C1 data/clock lines. It seems that the physical buttons have a cable that connects to the trackpad itself, which is how it works as a single unit:

Trackpad Buttons	Trackpad Assembly

[Qonfused]

(I'm really sorry I can't help much... it's a bit complicated with my courses (university) that take a lot of my time. I try as I can, I doubt I'll be cited in the credits for helping you a little... If I could be cited in the credits as a little help since a little bit the departure of this repo, I would thank you very much)

@UsedDiscord I think this is a fair request. You've been very helpful w/ this project, so I wouldn't undersell the time and effort you've spent here.

[Maleficent-Magik]

Oh?

I discovered that if you press CTRL, the right click menu works! (both CTRLs work)

So, you have to press CTRL and the right button to have the right click menu working... But, unfortunately, the left click while also pressing CTRL performs the same action, i.e. opening the right click menu...

So,

CTRL + C does not work, you have to do Windows + C to get the copy
CTRL + V doesn't work, you have to do Windows + V to get the paste
Right click of the trackpad doesn't work, you have to do CTRL + LEFT / RIGHT click to get the right button that works

What does the CTRL key do here? And why on the trackpad buttons especially?

[Maleficent-Magik]

@UsedDiscord I think this is a fair request. You've been very helpful w/ this project, so I wouldn't undersell the time and effort you've spent here.

@Qonfused , Thank you so much for your understanding, I appreciate it. This is a project that I like to be involved in, and despite the fact that there was Drama with one person (I won't mention the name, but shiecldk and you Qonfused was also involved) I still want to contribute.

Thanks to you for always supporting this project!

[Qonfused]

It seems that ctrl+click is another way to right-click on macOS: https://support.apple.com/guide/mac-help/right-click-mh35853/mac

[Qonfused]

I noticed there is a HIDEventServiceProperties dictionary under the Precision Touchpad driver (in IOReg), which has a property MouseButtonMode set to OneButton. There is also a MouseButtonDivision key set to 0x37, which might be used for separating left/right click functions based on x-position?

I currently don't know how these HIDEventServiceProperties get injected into the trackpad event driver (most look like macOS injects them). I created an injector kext for forcing the correct VoodooI2CHID drivers for the touchscreens (what was done previously in #12). If I can figure out how to inject these properties, there may not need to be any modifications made to the trackpad driver to get both physical buttons working.

[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:

https://user-images.githubusercontent.com/32466081/221356584-60768769-eb03-41a6-8e24-340926a505f2.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:

• https://github.com/VoodooI2C/VoodooI2C/pull/445#discussion_r606666672
• https://github.com/acidanthera/VoodooInput/commit/a1e92d7e401ae979be293a90c5cb5a033509ed96#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 https://github.com/VoodooI2C/VoodooI2C/pull/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 (https://github.com/acidanthera/bugtracker/issues/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 https://github.com/VoodooI2C/VoodooI2C/issues/527 issue for tracking. Until https://github.com/VoodooI2C/VoodooI2CHID/pull/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 109fcd5a28f4617da313dc78d0dfaa19d7095d11. You can find the latest oce-build from that commit here.

[Qonfused]

Fixed in https://github.com/VoodooI2C/VoodooI2CHID/commit/9ebbc8f823e54924dc24a43000a61c3e34cb6800. Thanks @1Revenger1 and @UsedDiscord!