Jump to content

dgsga
7,757 posts in this topic

Recommended Posts

EDIT: A new UEFI > AppleInput properties block has indeed been added to the config.plist for OC 0.6.8.  My complete list of EFI changes (including those required for OC 0.6.8 and some not required for OC 0.6.8) is here.

 

---------------------------------------

 

I think I'm seeing things...  Did a new UEFI properties block called AppleInput get added to config.list for OC 0.6.8?  Does this new UEFI > AppleInput properties block now include some properties that used to be in the UEFI > Input block?

 

		<key>AppleInput</key>
		<dict>
			<key>AppleEvent</key>
			<string>Builtin</string>
			<key>CustomDelays</key>
			<string>Auto</string>
			<key>KeyInitialDelay</key>
			<integer>0</integer>
			<key>KeySubsequentDelay</key>
			<integer>5</integer>
			<key>PointerSpeedDiv</key>
			<integer>1</integer>
			<key>PointerSpeedMul</key>
			<integer>1</integer>
		</dict>

 

Edited by tonyx86
  • Like 1
Link to comment
Share on other sites

On 4/3/2021 at 6:29 PM, iGPU said:

vit9696,

 

Thank you (and others) for all of your amazing work.

 

I'm using the latest OC releases (now v068 d3be085) under Big Sur 11.2.3. When ProcessorType is set to 0, I do not see recognition of the processor (AMD Threadripper 3970X). So according to the OC docs request, I'm attaching the results from sysctl machdep.cpu and dmidecode for this set up.

AMD-3970X-sysctl-machdep-cpu-results.txt 2.13 kB · 3 downloads AMD-3970X-dmidecode-result.txt 1.72 kB · 3 downloads

32C CPUs are unsupported by macOS.

  • Thanks 1
Link to comment
Share on other sites

CAUTION: Just a quick note on 0.6.8 and 0.6.9 config.plist: don't open it with OpenCore Configurator!

 

It adds back in all the removed entries and changes `AppleEvent" Settings from `Builtin` to `OEM`. And after that, you won't even be able to get in the bootloader.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, 5T33Z0 said:

CAUTION: Just a quick note on 0.6.8 and 0.6.9 config.plist: don't open it with OpenCore Configurator!

 

It adds back in all the removed entries and changes `AppleEvent" Settings from `Builtin` to `OEM`. And after that, you won't even be able to get in the bootloader.

 

Trust me on this one, 'OC Auxiliary Tools' app is the better option and far superior to the one you're referring to. OCAT now has a builtin updater that adds all new OC entries not only to the config.plist but to the major components i.e Drivers, plus a builtin auto OC Validate as soon as you open your config.plist.

  • Like 7
Link to comment
Share on other sites

@eSaF @5T33Z0 That’s just plain old lazy and risky to use apps like that to update and edit your config with plus you learn nothing from getting something to do it all for you. Use XCODE or PlistEditPro and make the changes yourself and you can learn the changes you’re making as you make them. 

Edited by AudioGod
  • Like 6
Link to comment
Share on other sites

@AudioGod Like repeating old stereotypes much? What do you think qualifies you to call me lazy? Have a look at my repos and then we continue this discussion. Do you have a built working hackintosh laptop with a dsdt-less configuration yet? Well I have.

 

And the reason I'd like to use OpenCore Configurator is to see all of the SSSDTs (around 20) and all of the patches (around 30) at once.

 

Keep your opinion to yourself, I don't care about it.

Link to comment
Share on other sites

@AudioGod I have created/edited all of my OC config.plists (currently through OC 0.6.8) with XCode (currently version 12.4).  I still feel that 'configurators' add uncertaintly as I'm debugging the configurator AND my configuration. However, This OC configurator does look very promising.  While I'm still using XCode to perform the editing, I just loaded my config.plist in the configurator and, using the built-in validator, found a few issues that I might need to correct.  It's not lazy - it's a tool: just know how to use it.

Edited by tonyx86
Link to comment
Share on other sites

What’s wrong with ocvalidate to check for errors?

Yes it is a tool but everything I said stands.

 

@5T33Z0 Calm yourself down mate. Yes it is lazy and risky. Does not mean I’m calling you a lazy person and sorry if I struck a nerve...:hysterical: 

Also there’s something called freedom of speech and I can say what I like to who I like and if you don’t like it then you know what you can do fella. 
 

DSDT free laptop...yeah and? Am I meant to be star struck by that or something or does it mean you’re some sort of god? Sorry man I didn’t realise I was in the presence of Hackintosh royalty.....What A Big Man You Are (not) :hysterical:

 

Edited by AudioGod
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

14 minutes ago, tonyx86 said:

It's lazy to use OCValidate.  Use diff against the sample.plist ;)

No it’s not, that’s just how to double check your work is correct if need be, It’s not like it’s making any changes for you is it bud?

Edited by AudioGod
  • Like 1
Link to comment
Share on other sites

13 minutes ago, AudioGod said:

What’s wrong with ocvalidate to check for errors?

Yes it is a tool but everything I said stands.

 

@5T33Z0 Calm yourself down mate. Yes it is lazy and risky. Does not mean I’m calling you a lazy person and sorry if I struck a nerve...:hysterical: 

Also there’s something called freedom of speech and I can say what I like to who I like and if you don’t like it then you know what you can do fella. 

 

What is it that makes you think OpenCore Configurator automates? It does nothing on it's own in terms of configuration… so your your argument isn't even valid… it's just a stereotype, like I said.

 

But hey, I bet you managed to configure your Ryzen built all on your own, without the pre-built patch collection for AMD Ryzen CPUs, because you are so god-like with OpenCore… :hysterical:

Link to comment
Share on other sites

Just now, 5T33Z0 said:

 

What is it that makes you think OpenCore Configurator automates? It does nothing on it's own in terms of configuration… so your your argument isn't even valid… it's just a stereotype, like I said.

 

But hey, I bet you managed to configure your Ryzen built all on your own, without the pre-built patch collection for AMD Ryzen CPUs, because you are so god-like with OpenCore… :hysterical:


no it doesn’t Oc auxiliary tools does. 
Anyway now you’re just talking pure rubbish mate. I never claimed to be anything big man. Stop being a 5 year old and showing off with you’re big words and small you know what and stop spamming this thread. If you want to have a problem with me then take it up with me private and il be happy to wind you up some more...lol


 

Link to comment
Share on other sites

@eSaF
OC Auxiliary Tools is an excellent and very complete app and I use it thanks to you. But don't forget corpnewt's ProperTree, a simple yet effective app with the ability to snapshot EFI/OC folders.

 

@eSaF @AudioGod @5T33Z0 @tonyx86

The big problem that OC Configurator has is that it must be updated for the exact version of config.plist because, if not, there will be missing or excess keys or even keys whose name, type or position have changed.
But if OC Configurator match config.plist version, it can be a tool that makes certain tasks more comfortable, although I am also in favor of plist editors (ProperTree, PlistEdit Pro, OC auxiliary Tool).

 

As audiogod says, what’s wrong with ocvalidate? It is not a config.plist editor, but in my opinion there is no better tool to check if config.plist is well formed. Provided that both are of the same version of OpenCore, exactly the same. Both elements are created by the same people, OpenCore developers. And ocvalidate is better than diff on sample.plist (imo, of course).

 

Edited by miliuco
  • Like 2
  • Thanks 2
  • Sad 1
Link to comment
Share on other sites

Guys (you know who you are), the flaming stops here. We've taken measures to control behaviour and content moderation will be implemented. Whilst everyone is entitled to his/her opinion on everything, there's absolutely no reason to become overly sensitive/upset on one hand and pour oil on fire on the other.

 

All OpenCore tools have their own benefits and disadvantages and each deserve credits to their respective authors. No need to make statements that are bound to hurt people who use them and insist on the matter.

 

MATTER CLOSED.

  • Like 7
Link to comment
Share on other sites

@miliuco - I totally agree Bro, if the config.plist is not up to date then you will get a conflicting data read out. I do have Proper Tree, PlistEdit Pro and OCAT on my system and believe use all three to cross reference everything is as should be. I have used the other one (the one that begins with M) and found each time it would add useless data i.e CPU type, instead of the entry '0' for auto it would place something completely different so I removed from my system and would not go near it again. To be fair I do not know if it has been improved since as OCAT is my goto plus it has an unofficial endorsement by Vit9696 the Man himself.

3 minutes ago, Hervé said:

Guys (you know who you are), the flaming stops here. We've taken measure to control behaviour and content moderation will be implemented. Whilst everyone is entitled to his/her opinion on everything, there's absolutely no reason to become overly sensitive/upset on one hand and pour oil on fire on the other.

 

All OpenCore tools have their own benefits and disadvantages and each deserve credits to their respective authors. No need to make statements that are bound to hurt to people who use them and insist on the matter.

 

MATTER CLOSED.

Sorry Have - just saw the notice.

  • Like 1
Link to comment
Share on other sites

I know that Bootloader Configurators have to resemble the latest feature set of the bootloader. Usually, I use ProperTree and PlistEditPro and OCConfigCompare. I only recently started using OC Configurator to manage SSDTs and ACPI Renames. Because once you have to handle more than 10 it's really becoming a drag to manage them all in a plist editor.

 

My only intent was to warn users about the current issue with OC Config Compare which is a fatal one in this case.

 

I had a look at the OCAF tool already. Seems promising. I just don't like that it looks like a Windows App.

 

EDIT: Version 2.33.1.1 just dropped and the issue has not been resolved. OC Configurator still sets Apple Event to 'OEM', even if you manually change it to "Builtin" and save.

Edited by 5T33Z0
Link to comment
Share on other sites

Can the schema defined in OcConfigurationLib be transformed into an .xsd, then the "xmllint --noout --schema config.xsd config.plist" command can be used to verify a config file? The .xsd could be included with the config.plist file so third party utilities can use it to verify the plist.

 

The names of fields for the config schema are in OcConfigurationLib.h and OcConfigurationLib.c. The fields are in a different order in each file though. Is there a reason the fields in OcConfigurationLib.h can't be alphabetical like in OcConfigurationLib.c?

 

It seems redundant to have the fields in more than one file. Can the redundancy be removed by using some preprocessor magic? Basically, put the schema in a separate file - make it contain only comments and invocations of macros, no other C code or #defines. When you need to do the declarations or code for the fields in a .h or .c file, do the #defines for the macros, #include the schema file, then #undef the #defines (maybe the #undefs can be at the end of the schema file). The schema file can be #included multiple times in the same source file using different #defines each time.

 

Maybe the schema macros can include the documentation for the fields. A tool can have #defines to printf the documentation from the schema file, then #include the schema to do the printfs. Then the .tex and .pdf can be built from the result of using the tool. This way the documentation will automatically match the source (at least for the fields part of the documentation). Maybe a similar tool can build an .xsd...

 

  • Like 1
Link to comment
Share on other sites

Yep here also,  newest OC Configurator displays an already existing  Buildin right  but changes the Event to OEM if you save it. 

 

Question ( a bit off OC topic but may be interesting) : I am now on OC 0.68 ,all OK.

But i used first time the Tool OC Auxiliary Tools which can validate (as OC Tool) and sjow Systeminfo.

Here i seen first time ever (i use same generated serial since a few years!) an Warning about Serial which contains an "I". Google for that gives info "I" is wrong.

Can i run in probs  with OC using that serial? Apple ID, App Store working (since a few years with that bad serial).

 

Bildschirmfoto 2021-04-07 um 07.59.54.jpg

  • Like 1
Link to comment
Share on other sites

@joevt Your idea is interesting but expensive. What would be the big advantage of the new verifying over ocvalidate?

Config options are "rarely" changed, we never released with out-of-sync scheme and docs as far as I am aware.

 

Don't get me wrong, I'm sure it'd be a nice idea if we were at the very beginning again. But we have a solution I'm not sure what kind of problem you're trying to fix of.

Link to comment
Share on other sites

@mitch_de I think Illegal characters can only mean  special characters like the vertical seperator "|" (Alt+7), not regular like letters like "l" (lower case L) or "I" (Upper case i). It could just be a bug in the App.

 

You could run GenSMBIOS and list your current SMBIOS to verify it.

Edited by 5T33Z0
  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...