Closed erkexzcx closed 6 years ago
daringer
commented
7 years ago Generally I do not see any problem to expose another "combined_temp", which is the max of both temperatures.
We're anyways won't go into the mainstream kernel, thus we can do any mess ;)
daringer
commented
7 years ago Shortly took a look into it, I believe this could be tricky, because the from the current ACPI interface used here, we only get the gpu temperature any others (at least 4 more for me) are provided by different other modules.
To actually make this work (kernel-based) it will likely need one of the following ways:
/sys/devices/platform/asus-nb-wmi/hwmon/hwmonX/temp1_input asus-nb-wmi module might give the right hints)The maybe wayyyyy simpler approach would be to do this in the user land. Like, a micro C-application, which will loop forever with a 1sec sleep to read and write the files. Eventually I thing kernel-space shall be fine, still struggling to get the data from another loaded module---haven't done rtfm obviously---need more reading material :smile:
daringer
commented
7 years ago This very much looks like is considered bad practice within the kernel to access sysfs-stuff (i.e., other temperatures) to have modules being as independent as possible .... nevertheless, this is and very likely will never be a mainstream kernel module, thus i might take the hackish approach..
"The internet" states this, but looks like here is even a walkthrough how to hack this into the kernel. Here there might be some ideas on how to directly access the appropriate hwmon device without the file system detour ....
Using this approach, this might be implemented, any volunteers? new hwmon attribute: temp_merged
erkexzcx
commented
7 years ago Hi Author,
For some reason I am unable to get GFX temperature on my fresh Arch Linux build - I will check and fill up bug if I wouldn't make it work.
I was already using "hacked" /usr/bin/fancontrol script. The workaround was so dirty, that I eventually forgot how I managed to get it working. The only thing I can think of is to make a modified fancontrol-like script, where user can define how each fan operates. I am not super good at bash scripting, but I can give it a shot.
erkexzcx
commented
7 years ago Maybe I am missing something, but what holds you from going into mainstream kernel?
erkexzcx
commented
7 years ago I understand this is pain for single developer to support such amount of devices. Looks like you've been overrun by NBFC tool :)
It works on all Asus notebooks you support + even the latest Zenbooks. I created arch wiki page here: https://wiki.archlinux.org/index.php/Fan_speed_control#NBFC
Don't worry, your tool is also there: https://wiki.archlinux.org/index.php/Fan_speed_control#Asus_laptops
In case you want to continue working with this project - I am here to help.
daringer
commented
6 years ago Mainstream Kernel As far as I understood, it won't be possible to go into the mainstream kernel using the ACPI based controlling approach, KastB made an approach to a non-ACPI based module. The full discussion is to be found here. If you have any experience, knowledge to share or add, feel free to re-open or just answer here.
NBFC mmmh, interessting---I might be wrong but, does NBFC actually support both fans for example for my laptop (Asus Zenbook UX32VD). Currently I am to swamped to actually take a closer look, but what I saw from a short scan/glance of github/website and code: 1) Pure user-land application (Might not be the preferred Linux approach) 2) Written in C# thus running using Mono on (Arch) Linux. Yes, I know this might be picky, but compared with asus-fan it will very likely eat magnitudes more of cpu-time (or in general: resources).
Well, I strongly believe this is one of the application designs that make Windows
soooo resource hungry compared to Linux. (Just a personal opinion, based on personal experience)
3) They have a pretty good "how-to-search-your-ACPI-for-fans-tutorial", love it! Despite that a tool, which allows testing the former findings... Fancy!
Under the line, I admit I was a little shocked, while reading your lines, but to be honest, my feeling is that the average computer user (Linux users included) might choose NBFC, but for the---how to say---enthusiast user, asus-fan might be the preferred solution.
Newer Zenbooks seem also to be easily supported by asus-fan, the only thing missing is time to invest (currently I am in a new-house-and-renovate-situation), but this will change soon and the proof-of-concept stuff is already there as far as I can oversee.
Anyways, much thanks for stating me within the ArchLinux wiki, as a first hour Arch user I am kinda honored :smile:
Thanks for sharing NBFC, seems a very legit approach and I will add it to the asus-fan README to enrich the "alternatives for asus-fan" list.
erkexzcx
commented
6 years ago Just to let you know - Yes, if you want to take control of both fans, then asus_fan is what I am talking about. For my new Asus UX430UQ (one fan, CPU and GPU), NBFC works fantastically, but heeeeeeeeeeeeeey, is that a mono wasting my battery. :D
daringer
commented
6 years ago haha :smile: well, C# is great, but heavy stuff, definitely too much overhead for a fan control from my point of view. Nevertheless, closing this issue, we are going a little off-topic here, have opened a new issue #55 for the actual feature...
Hi dev,
Let me show you why would I need a single file to output the highest temperature of both CPU and GFX.
For example:
Take a look at this picture (I own this Asus N550JV - this asus_fan module works great!) so you can have an idea (under picture I wrote some clarification):
So in conclusion, is there any capability to control fans on Linux using fancontrol script or any other tool like I described above? If you are not aware, then could you please implement this feature?
Here is one more exmple of how fans are deployed in Asus notebooks & zenbooks. See? One fan for CPU and another one for GPU isn't really good idea since I need both fans for CPU and one for GPU.