Jump to content

vit9696

Developers
  • Content Count

    623
  • Joined

  • Last visited

  • Days Won

    38

Everything posted by vit9696

  1. Hello, This is going to be a support/discussion topic of AppleALC on InsanelyMac. AppleALC is a kernel extension allowing you to enable native apple HD audio without any filesystem modifications. It dynamically injects the necessary modifications to AppleHDA (and other kexts) including the layouts, and makes your audio work starting from the OS installation. It should be noted that AppleALC starting with version 1.1.0 requires Lilu.kext to be put in the same folder as AppleALC.kext. See this topic for more details. For quite some time we are trying to obtain the necessary information about AppleALC codec compatibility. If you use something, please, consider checking the compatibility table (do not worry, it is in English), and report (here) on your codec. We are also looking for all the possible revisions of the codec, if we do not have the revisions listed for your codec please report as well. Thanks for understanding. The report is meant to contain: 1. Laptop model/Motherboard model 2. Codec name 3. Layout used with the info what works for you (ideally if you try them all) 4. OS X versions you tried 5. Autogenerated Info.plist made with the help of this utility. All the details including the source code are available on github: https://github.com/vit9696/AppleALC Some short wiki articles explaining the usage are included. As for now the project is relatively immature without practically any codec support. But it should be pretty easy to add more of them, I am hoping for the support of the "community" If you have any issues, better report them on github for structural reasons.
  2. SMC emulator with 2nd generation SMC support. Includes some monitoring plugins as API usage examples. New plugin additions are very welcome, given that they are well-written. Source code: repository. FAQ and documentation: link. Features and configuration: link. I wish to express my deep gratitude to all the people who worked on this project with me.
  3. vit9696

    OpenCore Discussion

    We think these features are impractical and have no plans for them. In case one needs to debug his configuration, he can always boot from USB and configure on a second computer. If this is not an option, there always is UEFI Shell, which provides easy file management enough not only to rename the files, but also edit their contents. This pretty much covers both the need to choose the configuration manually and the need to set different options. Picker GUI is not really meant to be a Flight Control Console, it is meant to be a way to optionally (as normally you hide it by default) provide an approach to choose an operating system to boot in a simple and intuitive way. Just like Apple BootPicker on a Mac.
  4. vit9696

    OpenCore Discussion

    @MacNB, OpenCore is not starting two times, it is just the way the flow goes, firstly an existing OpenCore instance is looked for, then a new one is allocated on failure. Currently there is no way to redirect early boot text to the log in OpenCore due to not yet loaded configuration. In theory it is possible to store this data to a temporary buffer, but we have not had much need in this so far. Reasonably clean patches implementing this feature is what we can merge though. Release builds should print nothing but warnings and errors (you have a debug build of ApfsImageLoader so you see its prints), this is how we designed OC and all other products. You can check a few pages back for more details on this choice. @telepati, we plan to merge ApfsDriverLoader to OpenCore in the future. For now you have to use it for APFS support.
  5. vit9696

    OpenCore Discussion

    This has already been answered many times, but long story short, we will not make ACPI patches OS-dependent. There are many reasons for them, and there is a good explanation here: .
  6. vit9696

    OpenCore Discussion

    Regarding picker issues, newly added BuiltinTextRenderer may improve the situation (it also supports HiDPI). @1Ale1, RequestBootVarFallback reduces the chance to run into the entry duplication bug. I.e. you may likely not face the bug when you have RequestBootVarFallback enabled if your motherboard is faulty. The bug may still happen even when RequestBootVarFallback is enabled, however. Even if you have both quirks (RequestBootVarRouting and RequestBootVarFallback) disabled you may still trigger the bug, but indeed with both of them off there is little chance it will happen. However, disabling RequestBootVarRouting will break functionality like switching between operating systems, remembering the default operating system, authenticated restart, unattended update installation, and several others.
  7. vit9696

    WhatEverGreen Support Topic

    IGPU? The only thing that affects IGPU performance is the framebuffer id. Most likely your setup is broken, simply, and you do not compare equivalent configurations (i.e. connector-full and connector-less).
  8. Base instrument for the interested developers. Implements kext and process patcher interface. Is used as a base in AppleALC and Shiki released earlier. Source code: repository. Usage: existing plugins and SDK. Pros (compared to existing bootloader patchers): Does not depend on a bootloader; Works in Recovery / OS Installer; Supports symbolic patcher; Enables kernel and kext API access; Allows process modifications. Control (via boot-args): -liludbg — enable debug printing (available in DEBUG binaries); -liluoff — disable Lilu; -liluslow — enable legacy user patcher; -lilulowmem — disable kernel unpack (disables Lilu in recovery mode); -lilubeta — enable Lilu on unsupported os versions.
  9. vit9696

    WhatEverGreen Support Topic

    It has never worked, as it is a new feature. I guess you could go MacPro/iMacPro way, it might work, but we have not tested it.
  10. vit9696

    WhatEverGreen Support Topic

    Should be shikigva=80, but it is not supported before 10.15, and RX580 drivers have a bug with it at the moment as of 10.15.2. No option for you at this step.
  11. vit9696

    OpenCore Discussion

    We were able to reproduce this. Filed as https://github.com/acidanthera/bugtracker/issues/669. Do not use this controller for now.
  12. vit9696

    VirtualSMC — SMC Emulator

    Clover has been unsupported by us since September. See this: https://github.com/acidanthera/bugtracker/issues/453 We do not intentionally break anything, but you are using it at your own risk with all our products.
  13. vit9696

    OpenCore Discussion

    @Sniki, I do not know anything about it to be honest, but maybe it is a good idea to raise a bugtracker issue.
  14. vit9696

    OpenCore Discussion

    Ugh, of course I meant RequestBootVarFallback. RequestBootVarRouting is needed on all hacks with OpenCore for default boot volume selection to work. Anyway, I guess, we will try to explore this issue and let you know if we find anything.
  15. vit9696

    OpenCore Discussion

    @floodlitworld, UsbKbDxe conflicts with AppleGenericInput in Clover. I would suggest you to remove it and check if there are any bugs. As for OpenCore, could you try removing FwRuntimeServices? macOS will not boot, but it is interesting to see if that affects the situation anyhow. Also, I do not think your motherboard needs RequestBootVarRouting. In addition to that, I remember X99 boards had serious issues with hashing services, please set HashServices to YES. @Mike Ranger, this means that some of the <data> fields in your configuration do not seem to be right. One can use OcSupportPkg/TestsUser/Serialized tool to debug configuration issues. Serialized.c contains the compilation command in the beginning of the file (clang -g -fsanitize=undefined,address …). Just compile it in Serialized directory and then pass your config.plist as an argument to see a verbose validation log.
  16. vit9696

    OpenCore Discussion

    @floodlitworld, this issue sounds like some pretty serious issue in your firmware. Did you have it with Clover? Did you use AppleUiSupport driver with Clover? If not, does it work for you? Also, you have OpenCore Debug mentioned in your signature, does the issue happen with release builds as well?
  17. vit9696

    OpenCore Discussion

    Not sure we can help with this. Does password menu appear quickly if you set KeySupport to NO? You may not be able to access OpenCore menu in this casem however.
  18. vit9696

    OpenCore Discussion

    @floodlitworld, try with 0. 60000 only applies to ASUS Z87 boards.
  19. vit9696

    OpenCore Discussion

    @Mike Ranger, ForceBoost was broken at the time you tried it. It should be fixed now, but indeed I strongly do not recommend it, as it maxes frequency. The quirk is designed for specialised setups. The PCI patch is implemented in master, but we cannot test it. @Sniki, generally we use WhateverGreen to disable discrete GPU. As for battery, I am afraid somebody else knows better. @floodlitworld, this sounds like an older Dell issue. Please check UEFI → Input preferences. Perhaps playing with the timer resolution will improve the situation for you. Also make sure there are no conflicting UEFI drivers, just in case.
  20. vit9696

    Different sensors projects

    iStat implements support for HWSensors sensors by explicitly detecting FakeSMC kext presence and using a dedicated SMC key mapping for it. It is up to them whether to also add support for Acidanthera sensors, but for obvious reasons we will not create a FakeSMC service in I/O Registry or add HWSensors SMC keys.
  21. vit9696

    Different sensors projects

    Hello, from our point of view there are serious terminology and organisation issues. — There exists a SMC emulator: FakeSMC or VirtualSMC. — There exists a driver providing sensor information: Intel Power Gadget kernel extension, macOS GPU kexts, Acidanthera Sensors or HWSensors. The driver does not necessary relate to the SMC emulator, as it can report sensor data with multiple methods. — There exists an application interpreting sensor information data: HWMonitor, HWMonitorSMC2, iStat Menus, etc. We believe it does not make sense to discuss sensor drivers and sensor applications in SMC emulator threads, they simply do not relate close enough to each other. The only case where we could imagine it be discussed is some API interaction with the emulator during driver development. From the presence of HWMonitorSMC2 in the first message we believe this is a joint thread for HWSensors (drivers) and HWMonitorSMC2 (sensor apps). So for us it makes good sense to request features for the latter here. If this thread is considered exclusive to HWSensors drivers, then it would be great if you create a dedicated thread for HWMonitorSMC2 for us to interact altogether. Moving messages to VirtualSMC thread is inadequare as VirtualSMC thread has nothing to do to sensors, and in fact it is even outside of the hardware sensors forum. Regarding our new sensors format, as we said previously, we added Super I/O data reporting through I/O Registry in raw format, and need application authors to interpret the data. The formats, modulators and demodulators differ a little, so we created a thread with datasheets here: https://applelife.ru/threads/datasheets-k-chipam-superio.2944734/. Cheers and thanks for understanding =)
  22. vit9696

    OpenCore Discussion

    @fabiosun, from the logs it looks like boot failed at boot.efi stage. Most likely due to memory allocation failure. Unfortunately we do not know any resolution at the moment and we also have no plans to perform any investigation as AMD is not a priority for us for the time being.
  23. vit9696

    OpenCore Discussion

    @pitrysha, thanks for the test, this makes good sense to me. @nmano, you do not understand what Cpuid1Data and Cpuid1Mask are, your values are garbage. See what @pitrysha did. Cpuid1Data D4060300 00000000 00000000 00000000 Cpuid1Mask FFFFFFFF 00000000 00000000 00000000 As for ProcessorType, you set 0xF01, but it is only compatible with 8, 10, 14, or 18 cores.
  24. vit9696

    OpenCore Discussion

    @pitrysha, in your archive you fake to a CPU without XCPM support, I don't know what for and hot it is supposed to work. Most likely it should be d4 06 03 or c3 06 03.
  25. vit9696

    OpenCore Discussion

    Hi @nmano, could you please explain why do you use patches for XCPM support for Xeons in a separate topic? OpenCore should have these builtin as explained in https://github.com/acidanthera/bugtracker/issues/365. We got a question from a user who found this and got very confused as this is definitely not what we designed. Cpuid1Data/Cpuid1Mask are a replacement for xcpm_bootstrap patch (and FakeCPUID), and they should really be <d4 06 03 00 (fake id)…> <ff ff ff ff… all zeroes> correspondingly. AppleXcpmCfgLock and AppleXcpmExtraMsrs should cover all the other patches Perhaps something went wrong? Could you please provide us with the details?
×