search

linux-on-mac / mbpfan

A simple daemon to control fan speed on all MacBook/MacBook Pros (probably all Apple computers) for Linux Kernel 3 and newer
https://ineed.coffee/projects/mbpfan
GNU General Public License v3.0
875 stars 138 forks source link

Add Hack for reading more sensors #228

Closed JoergOstertag closed 3 years ago

JoergOstertag commented 3 years ago

On my iMac late 2011 i replaced the broken HDD with a new SSD (Without Apple Thermal Sensor). After this I adapted the part of temperature reading to also read all Temperature-Sensors under /sys/devices/platform/applesmc.768 too. In addition I printed out the Sensor Labels for easier debugging.

JoergOstertag commented 3 years ago

On my iMac late 2011 i replaced the broken HDD with a new SSD (Without Apple Thermal Sensor). After this I adapted the part of temperature reading to also read all Temperature-Sensors under /sys/devices/platform/applesmc.768 too. In addition I printed out the Sensor Labels for easier debugging.

This substantially breaks my MBA 2014 setup. Before:

Old Temp: 64 New Temp: 64 Fan: Exhaust Speed: 1693

After:

Old Temp: 35099 New Temp: 35099 Fan: Exhaust Speed: 6500

I already read that some Macbooks have temperature sensors with really high of random values. To see more here and track down your problem with the high sensor reading I added Labels to the debug output. Now we should be able to see which sensor we might have to exclude. You can try the Version directly at: https://github.com/JoergOstertag/mbpfan

This PR has too many unrelated changes. Please narrow it and submit individual PRs for each one.

Concerning splitting the pull requests: Up to now I only used straight forward pushes; I am glad I got this pull request on the road ;-) But I think one thing is important before I continue here: Find out which code-formatter you use. Otherwise I'll go crazy with reformatting.

gaul commented 3 years ago

But I think one thing is important before I continue here: Find out which code-formatter you use. Otherwise I'll go crazy with reformatting.

Unfortunately this project does not have a consistent formatting (I am not the original maintainer, nor is the previous maintainer the original one). It would be nice to make it more uniform via clang-format although this would require some trial-and-error to find a minimal configuration that mimics what exists. If you want to take this up let's do it as a separate PR.

JoergOstertag commented 3 years ago

But I think one thing is important before I continue here: Find out which code-formatter you use. Otherwise I'll go crazy with reformatting.

Unfortunately this project does not have a consistent formatting (I am not the original maintainer, nor is the previous maintainer the original one). It would be nice to make it more uniform via clang-format although this would require some trial-and-error to find a minimal configuration that mimics what exists. If you want to take this up let's do it as a separate PR.

I personally would suggest to do a reformatting of the whole code to one of the commonly used standards. I would suggest to use either K&R (default build in Eclipse) or default clang-format. Yes this is a large change, but after this you should be save :-)

gaul commented 3 years ago

I personally would suggest to do a reformatting of the whole code to one of the commonly used standards. I would suggest to use either K&R (default build in Eclipse) or default clang-format. Yes this is a large change, but after this you should be save :-)

I understand style is important to some people but I maintain a bunch of projects and hacking out real functionality is what is important to me. If you can minimize this PR and follow whatever inconsistent formatting you can reopen or open a new pull request. As I said before, I will accept clang-format reformattings that stepwise move towards something consistent but I am not interesting in style changes intermingled with functional changes.