Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
If you're using a non-HiDPI display, UIScale should be set to AQ==.
That was stupid on my behalf! As I did the config.plist from scratch, I missed the UIScale value completely. Thanks for your work and help and sorry for waisting your time!
 
If you're using a non-HiDPI display, UIScale should be set to AQ==.
@cdf - you might want to mention in the first post that the default has changed - the huge icons happened to me as well and I figured that was what had happened and sure enough a change to non HDPI fixed it for me (I have a 27" Apple Cinema Display so no retina)

sfalatko
 
I have been looking at the Ridge stuff. But I think the speeds are not that awsome.
What do you mean? Is it suddenly slower as compared to Big Sur 11.2.3 booted through OC 0.6.7? The claim I had read is that Big Sur 11.3 wouldn’t boot at all if a USB 3.0 PCI card was used on a Mac Pro 5,1. Can you clarify any of this?
 
cMacPro refuses to recognize update from BS 11.2.2 to BS 11.2.3
Software Update displays: Your Mac is up to date. What I did was:
Installed OC 0.6.8 over previous version and replaced config file (no changes). Booted and works as expected, minus OS version update. And Apple store would not allow OS file download. Any thoughts on that. Thanks in advance.
 
The guide has been updated to OpenCore version 0.6.8.
Plistlib Generator 1.1.0 was released with support for OC 0.6.8 (see notable changes), you will need to perform few minor changes to your current setup.py file, prior executing the usual upgrade process.

@cdf, I've chosen the following AppleInput settings into setup.py example, the rest are all set to failsafe values:
Code:
        'UEFI': {
            'AppleInput': {
                'AppleEvent': 'Builtin',
                'CustomDelays': 'Disabled'
            }
As usual, all Plistlib Generator OC keys are set to failsafe values. However, if you set the CustomDelays to Disabled, it will automatically set the KeyInitialDelay and KeySubsequentDelay to right Apple values, so you don't have to specifically define them, like you did in your configuration. My goal is the change as little as possible the failsafe values.
 
Last edited:
  • Like
Reactions: Bmju
Installed OC 0.6.8 over previous version and replaced config file (no changes).
The configuration changed, see keys added and removed since 0.6.7 release. If you ran an even older version prior current upgrade, you have more changes, best you start from scratch. Refer to OC documentation for AppleInput settings and compare them with @cdf settings. Once you understand well OC, you can move forward to automate your upgrades with Plistlib Generator.
 
Last edited:
@startergo Proc shows the correct value now in 0.6.8:

Screen Shot 2021-04-06 at 1.31.53 AM.png


In Hackintool is still wrong:

1617687397236.png
 
Last edited:
My goal is the change as little as possible the failsafe values.

I suppose it's a matter of style more than functionality 🤔 but I tend to agree in this case. In fact, because KeySupport is disabled, why not also use the failsafe Auto for CustomDelays?

Note, however, that in cases where the values are actually used, Apple values should take precedence over the failsafe values. Consider for example SetApfsTrimTimeout. So you may want to use the Apple value of 1 for PointerSpeedMul.
 
  • Like
Reactions: Bmju
cMacPro refuses to recognize update from BS 11.2.2 to BS 11.2.3
Software Update displays: Your Mac is up to date. What I did was:
Installed OC 0.6.8 over previous version and replaced config file (no changes). Booted and works as expected, minus OS version update. And Apple store would not allow OS file download. Any thoughts on that. Thanks in advance.
I think there are almost certainly no changes in OC which are stopping this working. Are you still enrolled in the Mac developer or public beta program, if you already were? If not - or anyway - are you 100% sure that hybridization (aka board-id spoofing) is still set correctly? What is reported by ioreg -l | grep board-id?
 
Last edited:
cMacPro refuses to recognize update from BS 11.2.2 to BS 11.2.3
Software Update displays: Your Mac is up to date. What I did was:
Installed OC 0.6.8 over previous version and replaced config file (no changes). Booted and works as expected, minus OS version update. And Apple store would not allow OS file download. Any thoughts on that. Thanks in advance.
For BS updates you need to enable hybridization. See the section "Hybridization and related settings" in the Advanced Configuration (Part II) of the first post. Hybridization is not included in the basic config.plist that is part of the first post.
 
In Hackintool is still wrong:

The frequency reported by Hackintool may not actually be calculated. Check with dmidecode. In my case, there is a similar line:
Version: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz
This line is always the same with and without OpenCore. I suspect that in your case the frequency would be 3.47GHz... So it may not actually be "wrong."
 
  • Like
Reactions: Bmju and TECK
So you may want to use the Apple value of 1 for PointerSpeedMul.
These the failsafe values I use, taken from documentation:
Code:
                'AppleInput': {
                    'AppleEvent': 'Auto',
                    'CustomDelays': 'Auto',
                    'KeyInitialDelay': 0,
                    'KeySubsequentDelay': 0,
                    'PointerSpeedDiv': 1,
                    'PointerSpeedMul': 1
                }
 
As I gather, failsafes are not necessarily recommended, nor even always particularly useful.
`KeySubsequentDelay` failsafe is now (updated before release) 1, in fact.
I would suggest `CustomDelays` = `Disabled`, at which point values of 0 and 0 do make sense (since they are ignored).
I would also actually suggest placing `AppleEvent` at `Builtin` (which is the recommended value - all systems, no qualifications) in the docs. Specifically, even if you are not using configurable key delays, the OpenCore Apple Event implementation now features improved detailed mouse movement over Apple's version. Only 'Builtin' will always use OC's implementation.
 
Last edited:
  • Like
Reactions: cdf
`AppleEvent` at `Builtin` (which is the recommended value - all systems, no qualifications) in the docs.
The docs do indeed recommend this but most recommendations do not necessarily apply to real Macs; especially in cases such as this, where there is an OEM option which it says can be reliably used on Apple Hardware. Most will therefore tend to use that on real Macs.

Maybe recommended one needs to be added to as to make clear that it is even better than OEM?
 
  • Like
Reactions: Bmju
The docs do indeed recommend this but most recommendations do not necessarily apply to real Macs; especially in cases such as this, where there is an OEM option which it says can be reliably used on Apple Hardware. Most will therefore tend to use that on real Macs.

Maybe recommended one needs to be added to as to make clear that it is even better than OEM?
This was in fact removed:
Docs: Remove AppleEvent from ProtocolOverrides section (#251) · acidanthera/OpenCorePkg@905a4b6 (github.com)
 
This was in fact removed:
That's something else. AppleEvent was moved to be under a new AppleInput section.
This commit deletes the instance that was left under ProtocolOverrides (apparently forgotten).
 
  • Like
Reactions: Bmju
Note that the failsafe for PointerSpeedMul is actually documented as 0
The reason why I left it as 1 is because it did not make sense to have PointerSpeedDiv set to 1 by default, while
PointerSpeedMul set to 0. I would expect to have both values to 0 or 1, therefore I've chosen to apply an exception and set it to default Apple value.
 
I would suggest `CustomDelays` = `Disabled`
This setting does not matter if you have KeySupport disabled, therefore is set to failsafe Auto in Plistlib Generator default configuration.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.