Screen brightness and fan control fixes for Asus eeePC

Updated: May 6, 2019

This may sound like an odd topic. After all, my eeePC is 10 years old. But ... recently, I had it successfully restored to a full, meaningful new life with the use of MX Linux! Just about as I was to consign it to ashes, this nimble little distro made the netbook relevant once again, with decent performance, modern software and good looks. So not only am I happy, I'm amazeballsed.

There were two hardware issues with the netbook - screen brightness via Fn keys not working and fan control not kicking in. I had these SAME issues when I first got the device. Nevermind, let me show you how to fix these problems. We'll get the full range of Fn keys working again, and then sort the fans. After me.

Teaser

Screen brightness

We saw this back trick come up at the beginning of the decade. Some Fn keys work, some don't. The solution to the problem is to edit the GRUB configuration (command line). Like we did in the past, we need to tell the system to use the Linux ACPI specification. This is not default on this host, because it originally shipped with Windows 7 Starter edition.

You need some familiarity with the bootloader - but that's why my GRUB2 tutorial is for, eh. You will need to edit the /etc/default/grub file, and change the boot parameters - please back this file up before making the changes. Then, run the GRUB update. Very similar if not identical to what we had to do with my likewise-recently upgraded Vivobook machine, too.

sudo "text editor" /etc/default/grub

And then inside this file, change the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

To the following:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux"

Run the bootloader update:

sudo update-grub

After reboot, all the Fn keys ought to work.

Fan control

This is a more complex one, but still doable. We talked about this with Xubuntu in the past, and the basic steps remain quite similar. However, there are some small differences. To start with, I wasn't able to actually run the pwmconfig wizard and configure the fans:

/usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed

Here, I do need to thank iandw.net for the missing bits in this particular task. Combining my previous work on fan control with some of the extras outlined in the tutorial above, I soon had the fans whirring nicely and loudly, and the CPU temperature was going down all dandy like.

Well, the first step is to make sure pwmconfig will run correctly - and this requires another GRUB config change, but if you've done the above already, this one is almost like second nature. So you need the following:

acpi_enforce_resources=lax

Without the other change (acpi_osi=Linux), you get:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_enforce_resources=lax"

Together, it looks like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux acpi_enforce_resources=lax"

After reboot, the next step is to make the system detect available sensors:

sudo sensors-detect

Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

The text wizard will then ask you whether to add the detected module to the list of modules loaded by kernel during the startup. You can let it do that and then reboot. Or you can also manually load the module into the memory and continue.

Monitoring programs won't work until the needed modules are
loaded. You may want to run '/etc/init.d/kmod start'
to load them.

Unloading i2c-dev... OK
Unloading cpuid... OK

roger@netbook:~$ sudo /etc/init.d/kmod start
[info] Loading kernel module lp.
[info] Loading kernel module ppdev.
[info] Loading kernel module parport_pc.
[info] Loading kernel module loop.
[info] Loading kernel module coretemp.
[info] Loading kernel module ecryptfs.

You can then verify that coretemp shows by running lsmod | grep coretemp in a terminal window.

At this point, you can run the sensors command, to see whether fans are working:

sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +56.0°C  (crit = +100.0°C)

eeepc-isa-0000
Adapter: ISA adapter
fan1:        3904 RPM

Basically we're done, but we can also do more - we want a nicer temperature & fan program than the default, which is why we need to run the pwmconfig wizard once again. You will be asked some questions, and in the end, a configuration file will be generated under /etc/fancontrol that the fancontrol service will use. You can manually paste content there if you like and just restart the service. You can find two sample configurations in my older tutorial linked above. But let's do it step by step.

sudo pwmconfig

After you answer the prompts, you will see:

Testing is complete.
Please verify that all fans have returned to their normal speed.

The fancontrol script can automatically respond to temperature changes
of your system by changing fanspeeds.
Do you want to set up its configuration file now (y)?
What should be the path to your fancontrol config file (/etc/fancontrol)?
Loading configuration from /etc/fancontrol ...
Device path of hwmon1 has changed
Device path of hwmon2 has changed
Device name of hwmon1 has changed
Device name of hwmon2 has changed
Configuration appears to be outdated, discarded

Select fan output to configure, or other action:
1) hwmon1/pwm1           3) Just quit          5) Show configuration
2) Change INTERVAL       4) Save and quit
select (1-n): 1

You're not done. You actually need to configure the sensor(s):

Select fan output to configure, or other action:
1) hwmon1/pwm1           3) Just quit          5) Show configuration
2) Change INTERVAL       4) Save and quit
select (1-n): 1

Devices:
hwmon0 is acpitz
hwmon1 is eeepc
hwmon2 is coretemp

Current temperature readings are as follows:
hwmon0/temp1_input    60
hwmon2/temp2_input    53

Select a temperature sensor as source for hwmon1/pwm1:
1) hwmon0/temp1_input
2) hwmon2/temp2_input
3) None (Do not affect this PWM output)
select (1-n): 2

Enter the low temperature (degree C)
below which the fan should spin at minimum speed (20): 45
...

Once this step is complete, you can save and exit. And from that moment on, you should hear the fans speed up and down, governed by your CPU temperature. You can also manually play, changing values, and then starting or stopping the fancontrol service, to see the effect. But do we careful and don't blindly alter things.

sudo /etc/init.d/fancontrol start
[ ok ] Starting fan speed regulator: fancontrol.

Battery life

So the question is then, how does this affect - and/or improve the battery life? I didn't test this when I set the machine up with MX, but now that I have brightness control, we can talk about this. Well, we can't, because for some reason, the battery indicator always shows 100% and 4,200 hours. Infinite power! Reading online, this seems to be a bug that will be fixed in the one of the 5.X releases of the kernel.

Battery life, bug

Conclusion

That's it. After these two changes, my Asus eeePC is 99% configured, with (almost) full hardware compatibility. Apart from the battery indicator, everything works tiptop now, and the fans are doing their job in evacuating excess heat from inside the netbook chassis. The little machine is back in action, modern and relevant, with good performance and no hardware issues. Plus, we learned a few new things today.

We talked about GRUB2 bootloader, boot parameters, and the use of sensors tools and the pwmconfig command-line wizard. Best of all, MX Linux uses init rather than systemd, so it's even more fun playing around with services and whatnot. While I'm not happy that ancient issues haven't been merged into modern kernels and distro configurations, I am pleased that it's possible to resolve them in a relatively painless way. Well, we had two tasks, both done. Mission accomplished. See you out there.

Cheers.