Expand for all/more models

[danperks]

As there's a few people with different models working towards the same goal, is it worth opening up this repo for all models, having a "supported" table for each model and if necessary, separate EFI folders in the repo to support it. Happy to make the changes, but don't want to do it if we think it's not worth it.

[Qonfused]

That would be a good goal to work towards, though the main caveat is that @shiecldk has his repo for the UX582. At the very least I can support both UX581 variants, though I would be fine supporting the UX582 if it doesn't create any conflict.

I have a basic outline of some differences from the UX481 to address for the UX581/UX582 models:

• Check MATs support (I had already used the workaround assuming no MATs support)
• Add USB map (this will need to be verified as working for all UX581/UX582 variants)
• Add Thunderbolt patch
• Edit Framebuffer patch
• Edit GPU disable SSDT
• Edit GPIO pinning w/ VoodooI2CHID workaround

It may be best to work on these changes in a separate fork of this repository until at least those are addressed, and any remaining issues can be transferred over to this one. This can also be done through a pull request with the above included as tasks.

[Qonfused]

I'll add all model labels here explicitly, though generally applicable issues don't need to specify all three models.

[Qonfused]

I'll keep the UX582 label tentatively as @shiecldk's project is currently unmaintained. I think I'll at least create a PR for his repo addressing any needed changes.

[danperks]

I personally would say the best course of action is to "finish" this EFI (e.g. get to a point you may call v1.0) and then fork it off, fixing anything that's broken between other models. Ideally, you'd want to keep them as close as possible to each other to simplify maintenance and updates, so that seems like the most logical step. I understand everyone has different models so, but with a finished EFI in this repo + the knowledge from @shiecldk's repo, I would hope that it wouldn't require much work getting the conflicts resolved.

[Qonfused]

Yeah, that's definitely the way to go. I've been working on getting this project stable enough to where it is essentially in maintenance mode for the UX481 before going too far into that venture. Luckily the most difficult conflicts at the moment are reproducible on the other models as well, so most of the work left for the UX581/UX582 is incorporating those changes rather than fixing them.

[Qonfused]

I think I'll set up the project to explicitly override a base CFL/CML laptop config (or something unopinionated), using a configuration file that inherits/declares from a template base. Building source ACPI *dsl files can be built trivially with iasl, though there are some more advanced features like #include and other macros that might bend my current implementation a bit too far, which I'm not sure if I should support.

There's a build repo for virtually all kexts from Dortania, which makes fetching binaries by commit/release trivial. In the config.plist, Kext load order can be injected and verified using a similar trick to ProperTree (ordering CFBundleIdentifiers dependencies first), though a current issue is figuring how I'd specify max os versions for kexts.

I'm still figuring out how to handle the config.plist; the best solution so far seems to be applying overrides through a .diff file, which is simple to maintain.

Wanted to give an update as I've so far implemented building the EFI from the OCpkg source. As I get closer to addressing these issues, I'll update the roadmap and probably create a new discussion for it.

[Qonfused]

@shiecldk I've re-wrote the project since Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh#15 and Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh#19 to adopt a less strict BSD-3 license, but in a non-legal sense, it's still a fork of the original project. I've been behind in documenting changes for your repository (the bulk of them are in Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh#7, but I didn't make much progress there). My idea for the UX582 repo was to create a PR with any needed changes instead of hoisting this repo as a monorepo.

[shiecldk]

HI @Qonfused no worries, I think as long as our projects don't go for commercial use, it shouldn't be any issue. Feel free to use my project. Yes that sounds good. I can definitely work on the PR for my UX582 with you.

[Qonfused]

Just created a repo at https://github.com/Qonfused/OC-Build implementing most of #1. It is still a very early implementation; there aren't many rough edges, mainly missing features.

This is an example of how a single EFI can be composed, though this tool will also enable different variants of the same base config under the same umbrella repository. Handling of the config.plist isn't yet implemented, but the rest of this repo's source can be built this way currently.

Example project structure:

Example config.json

{
  "oc-version": "^0.8.8",
  "oc-build": "DEBUG",
  "include": {
    "*": [".contentVisibility"],
    "acpi": {
      "SSDT-AWAC": "./src/ACPI/SSDT-AWAK.test.dsl"
    },
    "drivers": ["AudioDxe", "HfsPlus", "OpenCanopy", "OpenRuntime", "ResetNvramEntry"],
    "kexts": {
      "Lilu": "acidanthera/Lilu=latest",
      "WhateverGreen": "acidanthera/WhateverGreen=latest",
      "AppleALC": "acidanthera/AppleALC=latest",
      "VirtualSMC": "acidanthera/VirtualSMC=latest",
      "SMCBatteryManager": "*",
      "SMCProcessor": "*",
      "SMCSuperIO": "*",
      "AsusSMC": "hieplpvip/AsusSMC=^1.4.1",
      "AirportItlwm-Ventura": "OpenIntelWireless/itlwm=^2.2.0",
      "AirportItlwm-Monterey": "OpenIntelWireless/itlwm=^2.2.0",
      "AirportItlwm-Big_Sur": "OpenIntelWireless/itlwm=^2.2.0",
      "AirportItlwm-Catalina": "OpenIntelWireless/itlwm=^2.2.0",
      "BlueToolFixup": "acidanthera/BrcmPatchRAM=latest",
      "IntelBluetoothFirmware": "OpenIntelWireless/IntelBluetoothFirmware=^2.2.0",
      "IntelBluetoothInjector": "*",
      "IntelBTPatcher": "*",
      "CpuTscSync": "acidanthera/CpuTscSync=latest",
      "DiskArbitrationFixup": "./src/Kexts/DiskArbitrationFixup.kext",
      "ECEnabler": "1Revenger1/ECEnabler=latest",
      "FeatureUnlock": "acidanthera/FeatureUnlock=latest",
      "HibernationFixup": "acidanthera/HibernationFixup=latest",
      "NVMeFix": "acidanthera/NVMeFix=latest",
      "RealtekCardReader": "0xFireWolf/RealtekCardReader=latest",
      "RealtekCardReaderFriend": "0xFireWolf/RealtekCardReaderFriend=latest",
      "RestrictEvents": "acidanthera/RestrictEvents=latest",
      "USBToolBox": "USBToolBox/kext=latest",
      "UTBMap": "./src/Kexts/UTBMap.kext",
      "VoodooI2C/VoodooI2CServices": "*",
      "VoodooI2C/VoodooGPIO": "*",
      "VoodooI2C/VoodooInput": "*",
      "VoodooI2C": "VoodooI2C/VoodooI2C=latest",
      "VoodooI2CHID": "*",
      "VoodooPS2Controller": "acidanthera/VoodooPS2=latest",
      "VoodooPS2Controller/VoodooPS2Keyboard": "*"
    },
    "resources": {
      "theme": "Acidanthera/GoldenGate"
    }
  },
  "exclude": {
    "*": [".contentFlavour"]
  },
  "build_dir": "./dist"
}

[shiecldk]

@Qonfused What's the difference between using SSDT-DDGPU.aml and SSDT-GPU-DISABLE.aml?

[Qonfused]

They do the same thing (calling the _OFF method for the dGPU), though I also have a fallback to using the S3 bumblebee method for suspending the GPU if it doesn't have an _OFF method.

[Qonfused]

@shiecldk I've implemented my oc-build tool with a new project structure for this repo in the linked PR (Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh#36). I can address or resolve any other questions/issues that need documentation.

[Qonfused]

@shiecldk Just added a changelog under docs/CHANGELOG.md in the development branch that you may find helpful for running down major changes in this repo. The 0.5.0 version is unreleased and describes changes in Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh#36.

I'll designate version 1.0.0 to the first stable release, following @danperks's suggestion.

[danperks]

Is it worth renaming the repository when appropriate to do so, on the off chance it could bring a few more people to the repo who own the other models but are also looking for EFI development?

[Qonfused]

I was thinking of creating a fork of @shiecldk's UX582 repo for the UX581GV/LV. Most likely the only changes that can't be upstreamed to the UX582 config would be model-specific USB mapping and framebuffer patches for the 9th gen model.

[Qonfused]

Resolved in 4756907, partially handled by #3.