Closed Maleficent-Magik closed 1 year ago
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.
So... some explanations. I updated, and deleted some Kexts that are completely useless... but also temporarily disable some kexts of VoodooI2C
So :
AirportItlwm.kext -> https://github.com/OpenIntelWireless/itlwm/releases/download/v2.1.0/AirportItlwm_v2.1.0_stable_Monterey.kext.zip
AppleALC.kext -> https://github.com/acidanthera/AppleALC/releases/download/1.7.4/AppleALC-1.7.4-RELEASE.zip
BlueToolFixup.kext -> https://github.com/acidanthera/BrcmPatchRAM/releases/download/2.6.3/BrcmPatchRAM-2.6.3-RELEASE.zip
BrightnessKeys.kext -> https://github.com/acidanthera/BrightnessKeys/releases/download/1.0.2/BrightnessKeys-1.0.2-RELEASE.zip
CodecCommander.kext (il me semble en erreur lors du démarrage) -> https://bitbucket.org/RehabMan/os-x-eapd-codec-commander/downloads/RehabMan-CodecCommander-2018-1003.zip
CPUFriend.kext -> https://github.com/acidanthera/CPUFriend/releases/download/1.2.6/CPUFriend-1.2.6-RELEASE.zip
CpuTscSync.kext -> https://github.com/acidanthera/CpuTscSync/releases/download/1.0.9/CpuTscSync-1.0.9-RELEASE.zip
DebugEnhacer.kext -> https://github.com/acidanthera/DebugEnhancer/releases/download/1.0.7/DebugEnhancer-1.0.7-RELEASE.zip
ECEnabler.kext -> https://github.com/1Revenger1/ECEnabler/releases/download/1.0.3/ECEnabler-1.0.3-RELEASE.zip
FeatureUnlock.kext -> https://github.com/acidanthera/FeatureUnlock/releases/download/1.0.9/FeatureUnlock-1.0.9-RELEASE.zip
HibernationFixup.kext -> https://github.com/acidanthera/HibernationFixup/releases/download/1.4.6/HibernationFixup-1.4.6-RELEASE.zip
IntelBluetoothFirmware.kext -> https://github.com/OpenIntelWireless/IntelBluetoothFirmware/releases/download/v2.2.0/IntelBluetooth-v2.2.0.zip
IntelBTPPatcher.kext (NEW !!) -> https://github.com/OpenIntelWireless/IntelBluetoothFirmware/releases/download/v2.2.0/IntelBluetooth-v2.2.0.zip
Lilu.kext (DEBUG VERSION!) -> https://github.com/acidanthera/Lilu/releases/download/1.6.2/Lilu-1.6.2-DEBUG.zip
NoTouchID.kext -> https://github.com/al3xtjames/NoTouchID/releases/download/1.0.3/NoTouchID-1.0.3-RELEASE.zip
NVMeFix.kext -> https://github.com/acidanthera/NVMeFix/releases/download/1.1.0/NVMeFix-1.1.0-RELEASE.zip
RestrictEvents.kext -> https://github.com/acidanthera/RestrictEvents/releases/download/1.0.8/RestrictEvents-1.0.8-RELEASE.zip
RTCMemoryFixup.kext -> https://github.com/acidanthera/RTCMemoryFixup/releases/download/1.0.7/RTCMemoryFixup-1.0.7-RELEASE.zip
SMC*.kext (include : BatteryManager, Processor, LightSenor & SuperIO) (Break?) : -> https://github.com/acidanthera/VirtualSMC/releases/download/1.3.0/VirtualSMC-1.3.0-RELEASE.zip
VirtualSMC -> https://github.com/acidanthera/VirtualSMC/releases/download/1.3.0/VirtualSMC-1.3.0-RELEASE.zip
VoodooI2C.kext & VoodooI2CHID.kext -> https://github.com/VoodooI2C/VoodooI2C/releases/download/2.7/VoodooI2C-2.7.zip
VoodooPS2Controller.kext -> https://github.com/acidanthera/VoodooPS2/releases/download/2.2.9/VoodooPS2Controller-2.2.9-RELEASE.zip
WhateverGreen.kext (DEBUG Version) -> https://github.com/acidanthera/WhateverGreen/releases/download/1.6.1/WhateverGreen-1.6.1-DEBUG.zip
XHCI-Unsupported.kext -> https://github.com/johnlimabravo/XHCI-unsupported/blob/master/XHCI-unsupported.kext.zip
Don't forget to change your series values please!
As Qonfused said :
Warning Please follow the below instructions before using this repository.
Please download [GenSMBIOS] (https://github.com/corpnewt/GenSMBIOS) and follow this guide for generating SMBIOS data for enabling iServices functionality.
About the trackpad:
3 fingers: open the window manager & search with Siri 2 fingers: up & down
2 fingers: secondary click
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...
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... 😂 😂
I made a mistake in the configuration, it is replaced.
If you have an error when starting MacOS, just download "config.plist" again ! and replace it ! I forgot a letter, sorry about the problem... I was tired haha...
ERROR : (line 1500)
Contents/MacOS/IntelBTPacher
FIXING BY :
Contents/MacOS/IntelBTPatcher
New config.plist uploaded !
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).
Oh I hadn't noticed, thank you!
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.
Missclick* (thanks to Google Chrome who scrolled down my page and clicked at the same time... my apologies)
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).
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.
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.
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...)
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.
Moved touchscreen issue to #12.
So, if we use Karabiner as planned, and we use 2 simple modifiers :
A) Button 2 -> Button 3
B) Button 3 -> Button 2
(As like on my screen)
this will solve the problem for the moment,
Left will be Right and Right will be Left...
But I have to test if it's normal that my trackpad goes very fast and not as usual...
So, "Solution not official right now"
update : Doesn't work right now... i need more time...
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 https://github.com/pqrs-org/Karabiner-Elements/issues/2370#issuecomment-674669989
Managed to fix the buttons with a reorder of kext plugins and adding voodoops2trackpad + voodooinput in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/commit/0b6711556207d49135466101fb8e217ab68704dd. I downgraded voodoo kext versions as part of this, but the same fix as proposed above should be applied when updating to newer versions.
PR merge on Jul 22 seems to address this issue: https://github.com/VoodooI2C/VoodooI2C/commit/9ab98319b6411c4a4822cc12f840df85cc684bfc
Update VoodooI2C Satellites and support for physical buttons (https://github.com/VoodooI2C/VoodooI2C/pull/514)
- Always pass buttons as pressure on single-button touchpads (fix https://github.com/VoodooI2C/VoodooI2C/issues/496)
- 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 (https://github.com/VoodooI2C/VoodooI2C/issues/499) and inability to use the right button with default settings)
- 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 usrsse2@me.com
Managed to fix the buttons with a reorder of kext plugins and adding voodoops2trackpad + voodooinput in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/commit/0b6711556207d49135466101fb8e217ab68704dd. 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
It did work consistently when I tried it then, but there has since been a regression since updating opencore. I believe the PR I just linked addresses this issue.
I know I'm stupid in terms of PR... but how do for get this famous Kext? and besides, is it normal that the keyboard does not backlight anymore? I know I'm asking a bit much I think? 😅
I had already built it in xcode but you can pull built versions from https://dortania.github.io/build-repo/ by commit.
There are some duplicate entries for Voodoo kexts+plugins in Kernel > Add
that I'll need to fix:
= VoodooPS2Controller (enabled)
= VoodooI2C > VoodooGPIO (enabled)
= VoodooI2C > VoodooI2CServices (enabled)
= VoodooI2C > VoodooInput (enabled)
= VoodooPS2Controller > VoodooInput (disabled)
= VoodooPS2Controller > VoodooPS2Keyboard (enabled)
+ VoodooPS2Controller > VoodooPS2Mouse (enabled)
+ VoodooPS2Controller > VoodooPS2Trackpad (enabled)
...
+ VoodooI2C (enabled)
= VoodooI2C > VoodooGPIO (enabled)
= VoodooI2C > VoodooI2CServices (enabled)
= VoodooI2C > VoodooInput (enabled)
+ VoodooI2CHID (enabled)
+ VoodooPS2Controller (enabled)
= VoodooPS2Controller > VoodooPS2Keyboard (enabled)
- VoodooPS2Controller > VoodooPS2Mouse (disabled)
- VoodooPS2Controller > VoodooPS2Trackpad (disabled)
= VoodooPS2Controller > VoodooInput (disabled)
The latter here should be the correct load order + settings.
Just fixed kext load order in 6249948b78853d7435534ecf6434b831fec87ac9.
I know I'm stupid in terms of PR... but how do for get this famous Kext? and besides, is it normal that the keyboard does not backlight anymore? I know I'm asking a bit much I think? 😅
Fixed Keyboard does not backlight by reorder the Kexts... (I have badly reorder the config.plist, mybad.)
But nothing right now for the Trackpad 😅
Just fixed kext load order in 6249948b78853d7435534ecf6434b831fec87ac9.
But nothing about Trackpad, it's exact? (See my last comment)
🤔
Looking at my DSDT (DSDT.zip) and the Device Manager in the ID Compatibles section, there is a difference!
Device (GPI0)
{
Method (_HID, 0, NotSerialized) // _HID: Hardware ID
{
If ((GPHD == One))
{
Return ("PNP0C02")
}
[...]
However, in the device manager, it is marked PNP0C50
This could cause a problem, no?
It may be a problem if it's occuping a pin that we want for the trackpad or one of the touchscreen displays, but currently they're not GPIO pinned so it shouldn't conflict for now.
I'd note that your firmware can also contain entries for devices that aren't present in your system (even for your specific config of this laptop there could be various models for something like the trackpad, etc).
It may be a problem if it's occuping a pin that we want for the trackpad or one of the touchscreen displays, but currently they're not GPIO pinned so it shouldn't conflict for now.
I'd note that your firmware can also contain entries for devices that aren't present in your system (even for your specific config of this laptop there could be various models for something like the trackpad, etc).
Ah yep I see.... Sorry I also try to get involved in the project so you are not alone, it's a bit discouraging to work alone and not have another person to test the project, I don't know if you know what I mean?< And also because I want to realize this project to put MacOS On this PC ^^'
So yes I make some mistakes sometimes ^^'
~See : https://github.com/VoodooI2C/VoodooI2C/releases/tag/2.7.1 - https://github.com/VoodooI2C/VoodooI2C/pull/514~
~Will may repair that bug, new update of VoodooI2C for 2nd button~
nvm didn't work...
It seems the trackpad buttons are using some generic HID interface; they don't use either of the PS2 mouse/trackpad plugins, but VoodooI2CHID. Device manager doesn't show any Synaptics/Elan SMBUS devices either so it's not a regular click pad.
Yes, otherwise we would have seen that it was a SMBUS or Synaptics...
So it would be more a problem related to VoodooI2CHID than VooodooI2C (And we necessarily exclude VoodooPS2 since it only manages the ATK 102 keyboard)
I checked the info.plist of VoodooI2CHID as well, the Compatible ID corresponds well to the one of the periophere manager. PNC050 (something like that)
Seems the PR I had linked to before was only fixing physical buttons on an actual trackpad; commit refers to digitiser/transducer buttons:
(part of https://github.com/VoodooI2C/VoodooI2C/pull/514/commits/524235cb372aca65a9150df58eeed14064c78e3f)
Also https://github.com/VoodooI2C/VoodooI2C/pull/445. The terminology used in these issues (and in VoodooI2C/VoodooI2CHID source) makes this very confusing to parse.
That's quite an interesting comment though...
Here, we are talking about pressure, which is quite interesting
Also here...
Here we talk about that: "there can be no secondary button without a primary button".
So, normally, if there is a primary button, you can have a secondary button...
Here we are talking about the Dell latitude 7390 2-1, why? It's a laptop with 2 buttons like the Asus ZenBook UX481, UX*** ect... What can interest us is that the left button was set to 2, and the right button was set to 3 and not 1
So, let's study this for the Asus Zenbook...
DEFINITION :
(uh... Github does not display the code as expected... bruh... Why? Idk because i'have read : GitHub Help... so... Mystery...)
It seems that most other devices with physical trackpad buttons are either connected via SMBus or are Synaptics clickpads; I can't find any other cases where there is an Elan trackpad w/ I2C buttons.
(uh... Github does not display the code as expected... bruh... Why? Idk because i'have read : GitHub Help... so... Mystery...)
Apparently, it only embeds the code preview when the permalink is referencing code from the same repository you're commenting on. It's rather problematic on an org level, since you may want to reference code from another project when talking about regressions/dependencies, or just manage a separate issue tracker in another repo.
I try to study a little by reading as I can (I do like that when I did not learn the programming language, I read and try to understand in the native language) VoodooI2CELAN.kext to understand how the Kext works...
I noticed that he is looking for things concerning the ASUS firmware... I have to continue to look at the different variants that exist...
bool VoodooI2CELANTouchpadDriver::check_ASUS_firmware(UInt8 productId, UInt8 ic_type) {
if (ic_type == 0x0E) {
switch (productId) {
case 0x05 ... 0x07:
case 0x09:
case 0x13:
return true;
}
} else if (ic_type == 0x08 && productId == 0x26) {
return true;
}
return false;
}
if (check_ASUS_firmware(product_id, ictype)) {
IOLog("%s::%s ASUS trackpad detected, applying workaround\n", getName(), device_name);
retVal = write_ELAN_cmd(ETP_I2C_STAND_CMD, ETP_I2C_WAKE_UP);
if (retVal != kIOReturnSuccess) {
IOLog("%s::%s Failed to send wake up cmd (workaround)\n", getName(), device_name);
return false;
}
Besides, we can forget the Gitter.im of Alexandred, it is not attractive in the sense that nobody answers / talks .
So, they don't offer Technical Support anymore, it seems. The only way to communicate would be Discord? or GitHub of VoodooI2C but in the "Issues" section : GitHub Issues VoodooI2C
Apparently, it only embeds the code preview when the permalink is referencing code from the same repository you're commenting on. It's rather problematic on an org level, since you may want to reference code from another project when talking about regressions/dependencies, or just manage a separate issue tracker in another repo.
Okay I'see, thanks ! I would use the famous ``` tags to signal code :)
Like that
``` << This things
@shiecldk Do you encounter the same button mapping issue using this kext load order?
VoodooI2C/VoodooI2CServices
VoodooI2C/VoodooGPIO
VoodooI2C/VoodooInput
VoodooI2C
VoodooI2CHID
VoodooPS2Controller
VoodooPS2Controller/VoodooPS2Keyboard
// Omit PS2Mouse / PS2Trackpad plugins
For reference, these are the kext versions tested with: Kext | Version |
---|---|
VoodooI2C | 2.7.1 |
VoodooI2CHID | 1.0 |
VoodooPS2 | 2.2.7 |
My Ux582 actually doesn't have the physics buttons as do in the 14-inch models. I assume I wouldn't encounter this issue? This is the sequence I use:
VoodooPS2Trackpad and VoodooPS2Mouse are not enabled.
Yeah the UX582 doesn't have physicals buttons, quite strange by the way as Trackpad...: (Picture from : Root-Nation)
Well, I guess it's a non-issue for you then. I don't know how I haven't noticed this before lol.
For the temporary fix of the trackpad freezing issue. Do you think it's possible to implement some SSDT codes to turn off the trackpad with FN+F6 (_Q12) like do through sleep and wake to get it back to work?
My _Q12 method does work for disabling the trackpad; for reference, mine looks like this:
Method (_Q12, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
If (!(DSYN & One))
{
If (ATKP)
{
^^^^ATKD.IANE (0x6B)
}
}
ElseIf (ATKP)
{
^^^^ATKD.IANE (0x6F)
}
}
I have ATKP enabled in the KBLC SSDT. I should probably move that over to its own SSDT; I didn't realize it was being used elsewhere.
@shiecldk Is the issue here that your trackpad doesn't wake from sleep? I'm not sure if VoodooI2C will reinitialize the device after calling this method, but it should do so anyways after sleep.
@Qonfused Sorry my texts made you confused, lol. I can disable the Trackpad with the _Q12. I was referring to the random freezing problem on the Trackpad; when the Trackpad freezew, I can, however, reenable it by putting the laptop to sleep and waking it to get the Trackpad response again. However, it would still freeze sometime at some point.
Hence, I thought maybe we could do some time with the _Q12 method to do the same thing that sleeps and wake the laptop on the Trackpad to temporarily bypass the problem.
I'm thinking of opening an Issue on VoodooI2C's GitHub about the Trackpad buttons swap because I don't feel like I can find a solution...
--- @Qonfused https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/8#issuecomment-1354068257 (Dec 15, 2022) --- 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.
If this can be reproduced, it should provide a much clearer picture of what is actually going on with the trackpad buttons. This may be blocked by a regression in VoodooI2C code.
I will take care of it soon, I am overwhelmed by my law classes...
I'm sorry... I could be free in 1 or 2 weeks to try to see what it changes
Looking into this issue again, it seems that versions 2.7+ recognize both trackpad buttons (not just the primary button).
Previous behavior in 2.6.5 not recognizing the second button was first resolved in version 2.7 due to this PR:
The very next commit in 2.7 pulls in changes from VoodooI2CHID, which notably incorporates some work from 1Revernger1 reworking gvkt's prior PR in #58:
^^ This last PR appears directly related to this issue as the trackpad must be using different report ids as a way to distinguish between the physical trackpad device and buttons.
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, after updating Kexts... the trackpad works!
CONNEXION : #4 #3