Confusing Info.plist values + Suggestion: Making Readme.md noob-friendly for widespread adoption
kaansoral opened this issue · comments
First of all let me say that I'm here just to disable Turbo Boost to start with, It's a craze right now, and everyone is using the closed source and paid solution, with all due respect for the marketing of that developer, we need an open source solution, and this project is a gem - It definitely deserves more attention (By the way, it seems that project is open source too, as I just stumbled onto it, my bad, but this project is better, since it's as simple as possible - I think even the dynamic configuration is redundant, but it would be nice to pre-configure max cpu multipliers)
However, I believe the initial Readme should should make it clear what the .kext does on default, and it should probably include the steps that you can only find here: #4
Currently, I'm hesitant to include the built Kext for example, because:
EnableTurboBoost: False Does this mean it'll disable TurboBoost on default? It would be less confusing as DisableTurboBoost: True
EnableProcHot: False Super scary, and why I didn't even try the .kext yet I don't want anything to do with the "ProcHot" flag, I have no idea whether the device is safe when it's on or off, what's the polarity of the flag - if it follows the EnableTurboBoost flag, it seems to disable the temperature protection by default, so it should've been EnableProcHot: True by default? Anyway, hope you get my point
As a developer I'm confused, and I believe non-developers will use this as well
yes - agreed it's not noob-friendly for the moment. On EnableProcHot to respond to your question, this just deactivate the BiDirectional ProcHot, which is the capability of the SMC for example to signal that something is hot. It does not deactivate the thermal protection of the CPU. In your case and with the current logic, you would need to have it to True, so that the BiDirectional ProcHot signal capability stays on.
Thanks for the suggestion @kaansoral !
I totally agree we should have a better document for a much user experience, as for now, I don't have any better idea to improve it (always headache at this :P), so any suggestion/PR would be very appreciated!
As for the way to config, I have some idea about splitting the project into 'Front end' (User Interface) + 'Back end' (control the MSRs), that's why dynamic control is needed so that CPUTune has a bridge to achieve it. Currently the UI is missing since I'm still improving/polishing the kext and ran out of time. @schdt899 who has better idea about how the application layer.
As for open source, yes, it is always open source like all of my other projects, no return ask!
As for solution, yes, it is more complicated since its flexibility, and also a much cleaner and more elegant way to read/write MSRs.
As for ProcHot, it sounds good to remove the 'scary' warning since modern CPUs protect against the overheating internally. cc @christophe-duc
As for Turbo, it's disabled by default with the slightly hard to read 'EnableTurboBoost = false', All features in Info.plist were with prefix 'Enable' so that it is more consistent, but I have no strong preference of either 'Enable' or 'Disable', we can create a poll for all users to vote.
As for a prebuilt release, this is a really good point which should be added to 'TODO'/'Wish' list.
Again, thanks for all the suggestion and let's make it better!