Jump to content


  • Content Count

  • Joined

  • Last visited

About Oliver@Cheme

  • Rank
    InsanelyMac Protégé

Profile Information

  • Gender
  • Location
    São Paulo
  1. Yes, no "BlackMode" variable is necessary. Just download the latest official Clover sources, and change the following values: in the files Settings.c and PlatformData.c, change the value from "gSettings.DefaultBackgroundColor" from 0x80000000 to 0xBFBFBF and in the file AppleUITheme.c, change the value of defined variable "BLACK_COLOR" to 0xBFBFBF. Recompile and reinstall Clover (replace all drivers as well) and that's it. The obtained Apple logo is gray and the progress bar is black. I don't know if there is a way to obtain black logo too...
  2. I changed the value of the DefaultBackgroundColor property to 0xBFBFBF (gray). I also added a property "BlackMode=0", to explicitly require gray boot, but I don't think this is necessary. I'm going to rebuild without it to test. Also works with 0xF0F0F0, or maybe, any other color.
  3. By changing a few things in Clover sources, I could finally get gray boot. Apparently, changing the value of the DefaultBackgroundColor variable (and using a smbios expected by boot.efi?) is enough. It seems pretty nice, for me there isn't the delay between the first and the second boot stage anymore like in the dark boot.
  4. Oliver@Cheme

    Clover problems report & features request

    Hello! It seems there is a bug with RC Scripts for saving nvram.plist in latest Clover revisions (e.g. 4586) when installed in legacy mode in Snow Leopard (10.6.8). The nvram is not saved and a forced shutdown is required (Normal shutdown does not occur when scripts are installed, the system stucks at final black screen before complete shutdown). After login, high CPU usage is verified when RC scripts are installed. Checking the System Monitor, this is caused by a process named SED. All these issues don't occur with newer releases of macOS. Is OS X 10.6 incompatible with latest versions of these scripts or is this really a bug? Thanks.
  5. Update: QE/CI seems work with Sierra kexts, with a little bug in the menu bar.
  6. If you open the binaries of Skylight and WindowServer in Hex editor, a list of other mentioned frameworks and libraries stored in /usr/bin can be seen. Maybe replacing all of these frameworks and libraries from High Sierra may permit the acceleration. I didn't try it yet. Anyway, if no boot is possible replacing Skylight, replacing other stuff may not help at all. Another thing to try is exclude Skylight or somehow disable it and substitute CoreGraphics and Quartz frameworks from El Capitan (Seems Skylight was introduced in Sierra). Just replacing kexts, I can boot in safe mode with loading of Framebuffer kext only, otherwise It stucks at a black screen.
  7. Oliver@Cheme

    Clover problems report & features request

    Thank you for your reply. This solution works very well for Clover, since it can see the new nvram.plist and so it recognizes nvram variables defined in a Chameleon boot session. I've written a bash script and used a daemon to do this at every boot. In the other direction, I've had to use PlistBuddy to edit a nvram.plist file in the formatting that Chameleon expects, so that it can see nvram variables defined in a Clover session. Now I'm trying to make this also "scriptized". Thanks again.
  8. Oliver@Cheme

    Clover problems report & features request

    Hello, Is possible to Clover recognize nvram plist files created for Chameleon based bootloaders (such as Enoch), since it has one already when emuvariable driver is used? I mean, if it could recognize and handle with these plist files, it would be possible to have only one plist file storing nvram variables visible and acessible to both bootloaders for the same system. This would be nice in a multibootloader installation. Thanks.